From:	noer AT cygnus DOT com (Geoffrey Noer)
Subject:	Cygwin32 1.0?
5 Mar 1998 16:53:37 -0800 :
Message-ID:	<199803050712.XAA05229.cygnus.cygwin32.developers@rtl.cygnus.com>
To:	cygwin32-developers AT cygnus DOT com
Cc:	noer AT cygnus DOT com (Geoffrey Noer)

I've just come back from a talk by Linus Torvalds who just gave a talk
about SMP issues in the Linux kernel to a large crowd of several
hundred at Cisco Systems.  It was really fun/interesting to hear him
speak on his recent Linux kernel work.  The main topic involved
his explaining his changes in use of kernel locks.  This reminded me a
lot of some of our past experiences with race conditions/deadlocks in
Cygwin32.

Although Chris' recent work in the signaling code seems to have fixed
the commonly occuring race conditions, the main reason why we've had
problems recently is that Cygwin32 was hacked together and never
designed.  At least, the design that emerged over time does not really
account for SMP or compatibility with multi-threaded applications.
Someone asked Linus tonight how he debugged race conditions and
deadlocks.  He said the best solution was not to write code with these
problems to start with and I think there's a good deal of truth in
that assertion.

In my copious free time :-), I've been reading the O'Reilly "Win32
Multi-Threaded Programming" book which discusses a lot of these issues
in more detail.  I'm starting to think we might want to do a redesign of
Cygwin32 to fix these issues at some point relatively soon.  This
wouldn't mean throwing out all of the existing code -- I think we
should talk about how Cygwin32 should be designed and then see how
much of the existing code could be reused.  When I was looking at the
use of the shared memory area, I found that adding locks would result
in deadlocks all too easily.  A significant redesign (if we did it
correctly :-) could solve these problems once and for all.

The overall goal would be to bring Cygwin32 out of beta and release
Cygwin32 1.0.  In addition to solving the SMP problem, I think we
would need to solve the rentrency problem so that multi-threaded
programs could safely use Cygwin32, perform other smaller cleanups,
and be in position to claim POSIX.1 (or other standards) conformance.

This is how it might work in terms of scheduling:

First:
* Get egcs/b19 Cygwin32 working together (by the end of March)
* Release bug fixed 19.1 cygwinb19.dll that addresses known b19
  problems.  (Maybe include egcs?)

Second:
* Cygnus has a stable current Cygwin32 version similar to b19
* We could then develop Cygwin32 1.0 in relative peace on a branch

What do you all think?  (Yes, this is very pie in the sky but...)

-- 
Geoffrey Noer
noer AT cygnus DOT com

- Raw text -