Changing threading semantics from init early to init before second thread

[Tor Lillqvist]

 > Robert McQueen wrote:
 > > This seems very appealing to me - pthreads are supposed to be the
 > > standard thread mechanism which everyone codes to. I even recall that
 > > win32 has a pthreads implementation floating around somewhere.

Yes, hosted by Red Hat even, at
http://sources.redhat.com/pthreads-win32/ . It's quite nice. (No
Cygwin or other Unix emulation involved, it's "simply" a very well
written pthreads API implementation on top of the native Win32 thread
API.)

Havoc Pennington writes:

 > It'd probably be better to abstract the windows native threads 

Nah, I would suggest just using the pthreads API, that is the
abstraction... Be careful to avoid nonportable pthreads usage, though:
For instance, one cannot portably compare pthread_t values directly,
one must use pthread_equal(). (pthread_t is a *struct* in
pthreads-win32, and also for instance in HP-UX.) And, there is no
portable "uninitialized" or "invalid" pthread_t value: One must use
separate boolean flags to indicate whether a pthread_t is valid or
not.

--tml