This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: fork failure?

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

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

>   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.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]