Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Date: Sun, 23 Sep 2001 22:34:46 -0700 (PDT) From: Matt X-Sender: To: Robert Collins Cc: Jason Tishler , Subject: RE: 1.3.4? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 24 Sep 2001, Robert Collins wrote: > > I'm leaning toward holding off releasing a threaded Python until your > > muto upgrade in complete. Do you concur? > > There's more than the muto change to make it "good". The second > statement (the wait) and other threads calling the signal() clause need > to be protected from each other. What that requires is a lock _that is > reset when the wait function is called_. This does not exist on 95 at > all (No SignalObjectAndWait). On NT that cannot be done for > CriticalSections at all, so I'm going to have to find somewaht to create > SignalMutoAndWait. I've some ideas, but nothing concrete just yet. (Any > realtime programmers want to pop up and offer some ring 3 assembler to > achieve this?) MSDN says MsgWaitForMultipleObjects can be used instead of SignalObjectAndWait in certain circumstances. While it doesn't support Critical Sections, it is supported on win9x. -- http://www.clock.org/~matt