On Wed, 17 Nov 2004 16:30:04 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:Gabe Schaffer <[EMAIL PROTECTED]> wrote: The problem is a different one: the COND_INIT macro just passes a condition location, the mutex is created in a second step, which isn't needed for windows. OTOH a mutex aka critical section is needed separatly.
So we should probably define these macros to be:
COND_INIT(c, m) COND_DESTROY(c, m)
see src/tsq.c for usage.
Does win32 require more info to create conditions/mutexes or would these macros suffice?
Win32 doesn't require anything else, but I don't think I like this idea. If you do COND_INIT(c, m) and Win32 ignores the 'm', what happens when some code goes to LOCK(m)? It would work under POSIX but break under Win32. I think there should be an opaque struct that contains c,m for POSIX and c for Win32.
This'll mean that every mutex will have a corresponding condition variable, something that I'm not sure we need.
On the other hand, I can't picture us having so many of these that it makes any difference at all, so I don't have a problem with it. It isn't a good general-purpose thread solution (there are plenty of good reasons to unbundle these) but we don't really *need* a general-purpose solution. :)
Parrot's locks will all have wait/signal/broadcast capabilities. We should go rename the macros and rejig the code. This may have to wait a little -- we're cleaning up the last of subs, I've still got the string stuff outstanding, and I promised Sam Ruby I'd deal with classes and metaclasses next.
So much time, so little to do. No, wait, that's not right...
--
Dan--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
