Messages in this thread |  | | | Subject | Re: POSIX message queues, 2.5.50 | | From | Peter Waechtler <> | | Date | 09 Dec 2002 00:33:04 +0100 |
| |
On Sun, 2002-12-08 at 18:38, Krzysztof Benedyczak wrote: > On Fri, 6 Dec 2002, Peter Waechtler wrote: > > > > > - our implementation does support priority scheduling which is omitted in > > > Peter's version (meaning that if many processes wait e.g. for a message > > > _random_ one will get it). It is important because developers could rely > > > on this feature - and it is as I think the most difficult part of > > > implementation > > > > Well, can you give an realistic and sensible example where an app design > > really takes advantage on this? > > > > If I've got a thread pool listening on the queue, I _expect_ non > > predictability on which thread gets which message: > > But someone could. When you implement POSIX message queues you have to > follow the standard and not write something similar to it. > Even if you mention in docs that your mqueues aren't strictly POSIX, > someone can miss it and end up with hard to explain "bug" in his program. > BTW as your implementation will act randomly I can't see how you will > handle multiple readers (maybe except some trivial cases). >
Just iterating over and over again does not produce the truth. It's not "random" - it's highly deterministic: the longest waiter will be woken up. EOT
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |