X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-3.5 required=5.0 	tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: sourceware.org
Message-ID: <4AD96A3B.6010901@cwilson.fastmail.fm>
Date: Sat, 17 Oct 2009 02:54:51 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: fork failure?
References: <4AD732C7 DOT 4020301 AT cwilson DOT fastmail DOT fm> <4AD73B83 DOT 9060505 AT gmail DOT com> <4AD74586 DOT 8070803 AT cwilson DOT fastmail DOT fm> <4AD752C8 DOT 2040908 AT gmail DOT com> <4AD7B135 DOT 6020401 AT cwilson DOT fastmail DOT fm> <4AD8220D DOT 8000908 AT cwilson DOT fastmail DOT fm> <4AD8AD47 DOT 6010605 AT cwilson DOT fastmail DOT fm> <4AD8B90B DOT 4040507 AT gmail DOT com> <4AD8CD8A DOT 7010708 AT cwilson DOT fastmail DOT fm> <4AD8D490 DOT 2040000 AT gmail DOT com> <4AD8DAC3 DOT 2080709 AT cwilson DOT fastmail DOT fm> <4AD93CA2 DOT 6020002 AT cwilson DOT fastmail DOT fm> <4AD95908 DOT 9020208 AT gmail DOT com>
In-Reply-To: <4AD95908.9020208@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Dave Korn wrote:
> Charles Wilson wrote:
> 
>> I have a hunch that an STC (okay, less-hellaciously-complicated test
>> case) could be developed, using just GNU pth and avoiding all the
>> libassuan/gnupg gobbledygook.
> 
>   Oh yuck.  So there's this alternative user-land pthreads library that runs a
> scheduler within a single real machine thread, using some hairy sjlj hackery
> to perform context switches?  That's kinda asking for trouble, isn't it?

Well, I haven't looked closely at it at all. I compiled it, it passed
its own testsuite, so I figured Great! moving on...

I was sorta under the impression that Pth acted as a wrapper around
pthreads if available, which seems relatively harmless. But maybe I was
wrong.

If, instead, we're NOT actually using real threads, but instead PTH is
faking them all within a single thread...well, (a) my guess about the
innards of frok::child and main_tls/my_tls is wrong, and (b) that's
just...evil.

>   Anyway, look here: pth_mctx.c line ~ 514

Well, we're not "windows" are we? I'll have to look, but I thought the
PTH configury was smart enough to treat cygwin as more unixy than that.

>   Umm, yes.  Poking around directly inside a sigjmp_buf.  Wonder if the layout
> is actually what that code expects it to be or not?  That's where I'd start
> looking next, anyway, if I was wondering why maybe things were randomly
> jumping to unexpected places ...

Oh gosh. I hope that code isn't actually "live" in the cygwin
build...yeah, messing around with jmp_bufs behind cygwin's -- or ANY
OS's -- back is just bound to screw up.  Sigh.

--
Chuck

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple