[M3devel] Why do we not check stackbase=NIL anymore in ProcessOther?

[Tony Hosking]

On 11 Dec 2009, at 10:02, Jay K wrote:

> I know what I was thinking, but it doesn't make sense any more.
> I could have sworn I saw a race where the value changed between
> the check and the subsequent read/use.
> That makes sense, in that I don't change the value under a lock.
> But it doesn't make sense, in that the changer should be suspended.
> The check is done shortly after in the C code though.
> There is just one read, and the purported race is gone.
> It should be ok. The one uncertainty on my part is what the HeapRep.FlushState does.
> I looked at, but I didn't follow through as to the other uses of the state it changes.

Ah, yes, I see the test now in the C code.  Doesn't make any sense that doing it there should make any difference though.

As for the flushing of the heap state, all that is doing is relinquishing the thread's heap allocation context so that GC can occur.

>  
>  
>  - Jay
> 
>  
> > Date: Fri, 11 Dec 2009 15:57:50 +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/12/11 15:57:50
> > 
> > Modified files:
> > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 
> > 
> > Log message:
> > Tidy a little.
> > Why do we not check stackbase=NIL anymore in ProcessOther?
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091211/49a747b7/attachment-0002.html>