| delorie.com/archives/browse.cgi | search |
Charles Wilson wrote: > Ach, the purist in me just wants to get pth working... Hmm...it appears the right way to do this is NOT to add another special case in pth: "no, on cygwin THIS is the way you poke around in the jmp_buf" + extra cygwin TLC in pth_fork(). Instead, cygwin pth should use the standard posix sigstack/sigaltstack approach. But that'll have to wait until after cygwin-1.7.1: http://cygwin.com/ml/cygwin/2009-07/msg00859.html > Let me add a new data point: I'll implement sigaltstack after 1.7.1 is > released. And, of course, cgf's statement above doesn't mean that sigaltstack will be available the day after 1.7.1 is released, either. I'm sure it will be devilishly tricky to get right, and will take a lot of time and effort. In the short-to-medium term, it looks like converting libassuan and gnupg to use pthreads instead of pth won't be terribly difficult. Once once sig[alt]stack is available I can modify cygwin-pth to use the sig[alt]stack "Machine Context Implementation" instead of the current "sjlj/sjljw32/none" one, and then restore libassuan and gnupg to the pth status quo ante. I think that pretty much ends this nightmare thread -- but chalk another vote up there for "pretty please, cgf, implement sigaltstack soonish". -- 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
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |