Re: [PATCH] pthread_fork Part 1

2002-09-17 Thread Thomas Pfaff
On Mon, 16 Sep 2002, Robert Collins wrote: > On Sat, 2002-08-17 at 06:18, Thomas Pfaff wrote: > > > > Rob suggested to break the pthread_fork patch into smaller chunks. Ths is > > part 1 providing a fork save key value handling. > > The patch will add a linked list of keys to< MTinterface and a

Re: [PATCH] pthread_fork Part 1

2002-09-17 Thread Robert Collins
On Tue, 2002-09-17 at 18:48, Thomas Pfaff wrote: > > I have attached a small source file for testing. Thanks. I've commited my reworked version. > My main goal was to get a working threaded perl, so this was the reference > source for the final testing. With all patches applied (and the chang

Re: [PATCH] pthread_fork Part 2

2002-09-17 Thread Robert Collins
On Sat, 2002-08-17 at 06:32, Thomas Pfaff wrote: > > Some small fixes in the pthread key handling. > @@ -1020,16 +1020,27 @@ pthread_key::~pthread_key () > int > pthread_key::set (const void *value) > { > - /*the OS function doesn't perform error checking */ > - TlsSetValue (dwTlsIndex, (voi

[PATCH] new mutex implementation 2. posting

2002-09-17 Thread Thomas Pfaff
This patch contains a new mutex implementation. The advantages are: - Same code on Win9x and NT. Actual are critical sections used on NT and kernel mutexes on 9x. - Posix compliant error codes. - State is preserved after fork as it should. - Supports both errorchecking and recursive mutexes.

Re: [PATCH] pthread_fork Part 2

2002-09-17 Thread Thomas Pfaff
On Tue, 17 Sep 2002, Robert Collins wrote: > On Sat, 2002-08-17 at 06:32, Thomas Pfaff wrote: > > > > Some small fixes in the pthread key handling. > > @@ -1020,16 +1020,27 @@ pthread_key::~pthread_key () > > int > > pthread_key::set (const void *value) > > { > > - /*the OS function doesn't

Re: [PATCH] pthread_fork Part 2

2002-09-17 Thread Robert Collins
On Tue, 2002-09-17 at 19:47, Thomas Pfaff wrote: > Agreed, I missed the point where magic is set to 0 if TlsAlloc has failed. > But i would really appreciate if you would apply the patch for > pthread_key::get that removes the set_errno(0) and preserves the WIN32 > LastError. > If you configure g

Re: [PATCH] new mutex implementation 2. posting

2002-09-17 Thread Robert Collins
On Tue, 2002-09-17 at 19:34, Thomas Pfaff wrote: > > This patch contains a new mutex implementation. > > The advantages are: > > - Same code on Win9x and NT. Actual are critical sections used on NT and > kernel mutexes on 9x. Are you saying it uses critical sections on NT? (i.e. is that MS's

Re: [PATCH] new mutex implementation 2. posting

2002-09-17 Thread Thomas Pfaff
On Tue, 17 Sep 2002, Robert Collins wrote: > On Tue, 2002-09-17 at 19:34, Thomas Pfaff wrote: > > > > This patch contains a new mutex implementation. > > > > The advantages are: > > > > - Same code on Win9x and NT. Actual are critical sections used on NT and > > kernel mutexes on 9x. > > Are

Re: [PATCH] new mutex implementation 2. posting

2002-09-17 Thread Robert Collins
Cool. I'll look into this in more depth tomorrow. Thanks for the updated patch! Rob signature.asc Description: This is a digitally signed message part

open () on Win95 directories

2002-09-17 Thread Pierre A. Humblet
As reported on Sunday in the Cygwin list, applications such as mutt 1.4 do not work on Win95/98/ME because there Cygwin does not implement open() on directories, as CreateFile () does not work on directories either. However often open () is used on directories with fchdir () or fstat (), which

RE: open () on Win95 directories

2002-09-17 Thread Gary R. Van Sickle
Hehehehe, I was just about to hit send on a reply to your original email on this Pierre! It wasn't going to have a nice patch attached though. Thanks for tracking this down and fixing it. -- Gary R. Van Sickle Brewer. Patriot. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[

RE: open () on Win95 directories

2002-09-17 Thread Pierre A. Humblet
At 08:18 PM 9/17/2002 -0500, Gary R. Van Sickle wrote: >Hehehehe, I was just about to hit send on a reply to your original email on this >Pierre! It wasn't going to have a nice patch attached though. Thanks for >tracking this down and fixing it. This problem is fixed, but there is another one!