On Sun, 21 Nov 2004 10:09:06 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > Gabe Schaffer <[EMAIL PROTECTED]> wrote:
> Currently we have COND only for the task queues. But if we need > conditions in other places, QUEUE_CONDITION is misleading. > So the current set of macros for existing stuff is ok? It should do. > > Also, note that with Win32 conditions you must indicate at creation > > time whether you want to Signal or Broadcast. Emulating POSIX > > semantics on Win32 are tricky, and it's probably overkill for these > > purposes. > > Yeah. I've looked at some emulation libraries. And right, we don't need > the emulation, we just need an equivalent functionality. I agree with this. However, it is entirely possible that somebody will assume one set of semantics and end up with a race condition that's hard to debug on another. > I'd say: just give it a try. Where semantics don't fit, we can either > abstract the inferface or put a few #ifdefs in place, which, given the > big differences in events/threads/process philosophy, should be ok, if > they don't clutter the source too much. That's no problem except where a given COND can be either signalled or broadcast to. Since Win32 cannot have a single condition that allows both, each instance will have to decide. In the case of your TSQ, e.g., it may be necessary to simply eliminate the queue_broadcast() function -- which is probably not a big deal because I don't see it called anywhere. GNS
