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?
Anyway, look here: pth_mctx.c line ~ 514
> /*
> * VARIANT 5: WIN32 SPECIFIC JMP_BUF FIDDLING
> *
> * Oh hell, Win32 has setjmp(3), but no sigstack(2) or sigaltstack(2).
> * So we have to fiddle around with the jmp_buf here too...
> */
>
> #elif PTH_MCTX_MTH(sjlj) && PTH_MCTX_DSP(sjljw32)
> intern int
> pth_mctx_set(pth_mctx_t *mctx, void (*func)(void),
> char *sk_addr_lo, char *sk_addr_hi)
> {
> pth_mctx_save(mctx);
> #if i386
> mctx->jb[7] = (int)sk_addr_hi;
> mctx->jb[8] = (int)func;
> #else
> #error "Unsupported Win32 architecture"
> #endif
> sigemptyset(&mctx->sigs);
> mctx->error = 0;
> return TRUE;
> }
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 ...
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
