Re: pthreads

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

Correction: I assumed that the pthread_cond* stuff would break without
checking or running that particular test program... the type goes from
two ints to a void*, so it works.

Rob (hiding face in shame).



----- Original Message -----
From: "Robert Collins" <robert.collins@itdomain.com.au>
To: <cygwin-developers@cygwin.com>
Sent: Monday, March 19, 2001 11:32 PM
Subject: pthreads


> Any objections if I do a <sarcastic>little bit</sarcastic> of
> housekeeping in pthread.h thread.cc & thread.h ? There's a few serious
> issues there with the type definitions (which I blindly followed for
> pthread_cond* - making it worse :[).
>
> I believe I can make it leaner and meaner, and more compatible/easy to
> build on in future....
>
> Fortunately I believe this can be done without breaking existing
> compiled programs (I'll especially test for this).
>
> As a side effect it will make some of it 64 bit clean.
>
> Rob
>
> Details for those who care:
> At the moment we have an number of fixed size arrays of multi-thread
> items, that we store a int index into for some of the pthread types,
and
> structs in userspace for the rest. The problem with structs is that we
> cannot change their size as we write more functionality in. (I went to
> do the patch for Norman Vine's question and realised I'd break the
ABI).
>
> Fortunately all the useable structs are 4 bytes long, as are all the
> index's. All those types should be pointers to objects created in
> cygwin1.dll, not userland variables.
>
> The housekeeping includes two things:
> * change the typedefs to be pointers so we can work more freely in the
> future,
> * and rewrite the guts of thread.cc & thread.h to allocate new objects
> on the stack and store the pointer rather than an index. This also
> removes the overhead of walking the list for user space requests, and
> simplifies the code.
>
> I've done a check on the typedef changes in pthread.h, and all my
> precompiled thread test programs still work fine* - so I'm confident
of
> the success of the change.
>
> * With the expected exception of pthread_cond* variable access. But
> that's not even in a snapshot yet, so I don't consider it a problem.
>
>
>
>