Mail Archives: cygwin/2005/08/15/01:21:50
On Mon, Aug 15, 2005 at 02:56:44PM +1000, Bitmead, Chris wrote:
>>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.
Yes, I know. Unless I implement this *crucial* bit of functionality it
is possible that the space time continuum will implode.
However, since it is not currently implemented, since there is no sign
of an implementation on the horizon, and since it may be impossible to
implement for Windows, that does present a problem for your
implementation on cygwin.
>>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.
Ack. You're right. I even made the point about the frame pointer and
then lost it ten minutes later.
However, I'm not sure you can rely on the fact that the frame pointer is
being used for everything, especially if the code is near the function
prologue. I suggested before that maybe you should mention what you're
doing in the gcc mailing list. I'm sure that people there would tell
you if what you are doing is safe.
>>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.
Using posix threads is going to be quite a bit more portable than
writing assembly language to set ESP, especially if you branch out into
non-x86 platforms.
I mentioned thread pools rather than thread because the thread pool
technique reduces the overhead involved in setting up a thread for every
function call. Using a thread pool would certainly be slower than
simple function calls, though, that's a given, although if you are
calling malloc for every new invocation of a function, there is
overhead, there too.
cgf
--
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 -