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
