[M3devel] SaveRegsInStack / awkward SignalHandler, etc.

[Tony Hosking]

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/097321a8/attachment-0002.html>