www.delorie.com/archives/browse.cgi | search |
Charles Wilson wrote: > 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. My first thought would be to figure out what pth is attempting to do while messing in jmp_buf, and make it work. It's bad, unmaintainable code, that will break again in the future if ever jmp_buf is rearranged - but it only has to stagger along for another couple of months until you can do it right using sigaltstack. Until then, slapping a band-aid on pth might be a lot less work-that-soon-has-to-be-thrown-away than hacking both libassuan and gpg to handle a different API. (I say this without having yet done the research to figure out exactly what pth thinks it is doing to that jmp_buf and whether it's necessarily possible, but it ought to be.) Anyway, it's your effort so it's your call but I suggest this strategy because you didn't explicitly mention having considered it in your deliberations above. cheers, DaveK -- 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 |