Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <602EF4562299D711978800065BEECE9A0D2D30D5@cbrml50.ag.gov.au> From: "Bitmead, Chris" To: "'cygwin AT cygwin DOT com'" Subject: Re: Cygwin.dll crash, alloca and custom stack Date: Mon, 15 Aug 2005 14:56:44 +1000 MIME-Version: 1.0 Content-Type: text/plain >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/