Mail Archives: cygwin/2005/08/15/00:57:05
>As I mentioned previously, cygwin uses the stack for thread local
>storage so you can't just create a new stack and expect things to work.
>You've worked around that by wrapping cygwin function calls with
>save/restore operations.
It's not clear to me why cygwin threads should care where their stack is.
But doesn't matter, there are other good reasons to use the system stack
before calling random C functions.
>I've heard of sigstack and sigalstack but cygwin hasn't.
Well that's a shame since sigaltstack is part of the base specification for
X/Open UNIX. If cygwin wants to become UNIX compatible it needs to implement
it.
>you can no longer access any variables in the enclosing stack frame
>and, given optimization, you don't always know precisely where this
>block of code will show up wrt the rest of the code in the function.
Actually, you can still access variables because variable are offset from
fp, not esp. One can't use omit-frame-pointer, but I can't expect to be
switching calling conventions when playing around with assembler. And the
reason fp isn't a problem is because function calls automatically push fp
onto the (new) stack, so it is restored on function return.
>You may be able to control this, to some extent, with the use of the
>volatile keyword.
I can't see that this would help.
>Maybe I don't understand precisely what you're trying to do but it seems
>like you could get the behavior you're looking for by setting up some
>thread pools and just switching to a new thread when it is time to call
>one of these functions which needs its own stack. On Windows you could
>also use fibers, rather than threads, I believe.
Quite possibly, but fiddling around with threads could well be a lot more
overhead, and possibly even less portable. I don't particularly want to
have a context switch happening every time I call a function in the
interpreter.
I'm not even sure if I could control the thread so that it can't be
interrupted
until it returns. But it is a possibility if other avenues become a problem.
But it would feel
more like an admission of failure about how I'm doing it if I had to do
that.
>So, again, the only thing you may have to worry about are cygwin signals
>and windows exceptions.
And what is the issue with windows exceptions? Is it another case of needing
extra stack space for safety?
-----------------------------------------------------------------
If you have received this transmission in error please notify us
immediately by return e-mail and delete all copies. If this e-mail
or any attachments have been sent to you in error, that error does
not constitute waiver of any confidentiality, privilege or copyright
in respect of information in the e-mail or attachments.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -