[M3devel] SaveRegsInStack / awkward SignalHandler, etc.

[jay.krell at cornell.edu]

(sorry I know it sounds rude)
I already had & my comments had it in mind.

  - Jay (phone)

On Nov 26, 2009, at 3:59 PM, Tony Hosking <hosking at cs.purdue.edu> wrote:

> Take a look at the latest and see what you think.
>
> On 26 Nov 2009, at 15:01, Jay K wrote:
>
>> Ok I guess. Then the setjmp should be under #ifdef  
>> M3_REGISTER_WINDOWS. ?
>> (In ProcessOther, not ProcessLive.)
>> Wait...doesn't ProcessLive need a setjmp or getcontext??
>> I can buy the notion that:
>>
>>  > The heap references we are interested in will be somewhere on  
>> the stack.
>>
>>
>> You are certain?
>> This is the main difference.
>>
>>
>> Also, if we can be so loose about it, then the extra function call  
>> isn't needed either, right?
>> Just the old ADR(xx) (or ADR(me) or ADR(errno), no need for another  
>> variable).
>>
>>
>> My approach as I said was more well defined, but as you say, maybe  
>> no need for it.
>>
>>
>> (Itanium looks easy enough; setjmp/longjmp to flush registers,  
>> getcontext to get the current bsp, get the current bsp in thread  
>> create and then scan between that and whatever getcontext returns  
>> later, and __libc_ia64_something_or_other for the first thread, and  
>> a hardcoded constant on FreeBSD/IA64 -- this per a quick read of  
>> the Ruby code it turns out.. HP-UX and VMS on IA64 TBD..Windows is  
>> probably trivial, what with compiler intrinsics...)
>>
>>
>>  - Jay
>>
>> Subject: Re: SaveRegsInStack / awkward SignalHandler, etc.
>> From: hosking at cs.purdue.edu
>> Date: Thu, 26 Nov 2009 14:21:14 -0500
>> CC: m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>>
>> On 26 Nov 2009, at 14:11, Jay K wrote:
>>
>> Tony I agree my code was "awkward" (what I'd really like is for cm3  
>> to output .h files
>> so that interop can be "natural", reliable, clear, idiomatic,  
>> correct.. but until then..)
>> (And if such .h files were output, I'd just write the entire signal  
>> handler in C.)
>>
>> However I found the meaning and correctness of my code clearer.
>> In particular I was getting the registers into the stack keeping
>> the stack below their location.
>>
>>
>> In your case, you know, sem_post/sigsuspend will overwrite part of  
>> that.
>>
>> We don't care that it is overwritten.   We just need a reasonable  
>> approximation of the top of the stack.  The heap references we are  
>> interested in will be somewhere on the stack.
>>
>>  Now, I grant, it isn't all clear -- your code has a high chance of  
>> being correct.
>> The (current) registers probably are already higher up the signal  
>> call stack.
>> So the stack pointer for the signal handler itself probably  
>> suffices -- what
>> you were using prior to yesterday.
>>
>> Right.  We just needed to make sure that the Windows were saved on  
>> SPARC.
>>
>>  "Briefly: I like the way I had it." (except, again, yes the C <=>  
>> Modula-3 interop is "awkard").
>>
>> I had problems with the blurring of the ActState enumeration across  
>> the C/M3 boundary.
>>
>>
>> ?
>>
>>  - Jay
>>
>>
>> > Date: Thu, 26 Nov 2009 19:44:24 +0000
>> > To: m3commit at elegosoft.com
>> > From: hosking at elego.de
>> > Subject: [M3commit] CVS Update: cm3
>> >
>> > CVSROOT: /usr/cvs
>> > Changes by: hosking at birch. 09/11/26 19:44:24
>> >
>> > Modified files:
>> > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.i3
>> > ThreadPThread.m3
>> > ThreadPThreadC.c
>> >
>> > Log message:
>> > Refactor slightly to avoid need for awkward SignalHandlerC call.
>> >
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091126/9b726f0a/attachment-0001.html>