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: GNU pth + cygwin + fork [Was: Re: fork failure?]

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.


Problem reports:
Unsubscribe info:

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