From:	noer AT cygnus DOT com (Geoffrey Noer)
Subject:	Re: cygwin32-developers problems?
9 Mar 1998 21:23:29 -0800 :
Message-ID:	<199803100309.TAA05291.cygnus.cygwin32.developers@rtl.cygnus.com>
References:	<199803100128 DOT UAA08056 AT hardy DOT bbc DOT com>
To:	cgf AT bbc DOT com (Christopher Faylor)
Cc:	cygwin32-developers AT cygnus DOT com

Christopher Faylor wrote:
[...]
> The main thing I remember typing was that you could make a case that
> Linus had it easy compared to Cygwin.  If something isn't working quite
> right in the kernel he can implement it.  If he needs a nifty new
> synchronization primitive he can just code one into linux.

We do have complete control over our Cygwin kernel so I don't think
our job is particularly harder but it is certainly as hard.  We have
access to a large enough variety of locking primitives that I don't
think we need to write any.  :-)

If we only care about supporting single-threaded applications using
cygwin.dll, our task would be easier because we only would have to worry
about having locks around the shared memory.  Right now, we don't do
this and when I spent a small amount of time looking into doing this
it seemed very difficult because of the current design.

Ultimately, we would like to support multi-threaded programs using the
cygwin.dll which means we also have to worry about accesses to the
per_process structs as well.

> I do agree that it would be nice to take a step back while we scratch
> our heads and theorize about the best possible way to reimplement various
> things in Cygwin to make them more thread safe but I think that just
> "designing them right from the start" is going to be a very elusive task
> because there are so many variables to juggle.
> 
> Some kind of design document detailing current design and projected
> future enhancements would probably be invaluable for this purpose, however.

I agree.  I just meant that we ought to decide how locking ought to be
handled and be ready to do some serious rewriting if that proved
necessary (and my hunch is that it will be but hopefully I'm wrong).

> You also mentioned that their was an SMP problem and I'm not sure what that
> is.

I meant the issue described above -- there are still several race
conditions that are possible that I would like to eliminate without
making deadlocks possible.  :-)

-- 
Geoffrey Noer
noer AT cygnus DOT com

- Raw text -