On Mon, Dec 02, 2002 at 09:13:20AM -0800, Thomas Bushnell, BSG wrote: > Roland McGrath <[EMAIL PROTECTED]> writes: > > > > We still need a way to keep track of what they are, and the existing > > > mechanism is basically the only way. We can either implement it with > > > a wrapper around pthread conditions, or exted pthread conditions. The > > > latter seems better. > > > > Or, as I suggested, all the users (all four of them) of this interface > > could just use the standard interface instead, i.e. signal several conds. > > Right, and like I said, they need a way to keep track of which > conditions they need to signal. They will probably hold them on a > linked list, and call one function that signals the lot. Oh wait! > That's what we have now! > > So the question is only whether this is to be layered on top of > pthreads, or an extension of pthreads.
Roland was talking about hard coding the knowledge into the code. Ie, a very simple condition_signal (cond1); condition_signal (cond2); instead some foobar_signal(cond1) which somehow dynamically works out what conditions are implied by cond1. I like the nice modularity and runtime flexibility that implied conditions give you, but I see Roland's point: We don't really need it in our code. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org [EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/ _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
