Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 9 Dec 2002 19:49:02 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 9 Dec 2002 19:49:02 -0500 Received: from tmr-02.dsl.thebiz.net ([216.238.38.204]:51983 "EHLO gatekeeper.tmr.com") by vger.kernel.org with ESMTP id ; Mon, 9 Dec 2002 19:49:01 -0500 Date: Mon, 9 Dec 2002 19:55:03 -0500 (EST) From: Bill Davidsen To: Peter Waechtler cc: Krzysztof Benedyczak , linux-kernel@vger.kernel.org, wrona@mat.uni.torun.pl Subject: Re: POSIX message queues, 2.5.50 In-Reply-To: <1039390666.19736.1.camel@picklock> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2131 Lines: 48 On 9 Dec 2002, Peter Waechtler wrote: > 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. I think your original post saying you expect non-predictability is/was very misleading. I think you meant the application can't make assumptions based on knowing which thread will be scheduled next, but even then the truth is that if it is always deterministic then assumptions could be legitimately be made. If it was random then a thread could wait forever, and Murphy's law says it would happen most of the time:-( -- bill davidsen CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. - 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/