Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Message-ID: <012c01c0b078$f8d8b650$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin-developers AT cygwin DOT com>
References: <011c01c0b070$9f8ae6c0$0200a8c0 AT lifelesswks>
Subject: Re: pthreads
Date: Tue, 20 Mar 2001 00:31:51 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime: 19 Mar 2001 13:26:17.0534 (UTC) FILETIME=[2DAE5DE0:01C0B078]

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 DOT collins AT itdomain DOT com DOT au>
To: <cygwin-developers AT cygwin DOT 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.
>
>
>
>