[M3devel] ThreadBase/RunThread

[Jay K]

ps: I think there might be a problem here if the compiler is aggressive.

But I haven't been able to prove it.

Maybe the LOCK implying volatile makes it ok?

Maybe the compiler won't inline anything with a volatile local??

 

 - Jay

 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Mon, 9 Nov 2009 00:14:01 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] ThreadBase/RunThread
> 
> 
> I think another problem is that pthread_setspecific_activations + LOCK in the same function might not mix.
> 
> pthread_setspecific_activations only occurs twice in the code base, very special.
> 
> It should be left alone.
> 
> 
> 
> - Jay
> 
> 
> 
> 
> CC: m3devel at elegosoft.com
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Subject: Re: ThreadBase/RunThread
> Date: Sun, 8 Nov 2009 19:08:12 -0500
> 
> 
> 
> 
> 
> There should be no traced references manipulated in ThreadBase.
> 
> 
> In RunThread, self is kept live by simply holding it on the stack.
> 
> 
> You will probably have trouble eliminating the slots array. We need a global to hang on to the traced Thread.T. How else do you propose to associate untraced pthreads with their traced Thread.T?
> 
> 
> On 8 Nov 2009, at 18:05, Jay K wrote:
> 
> ThreadBase/RunThread -- something seems a little off to me here.
> 
> 
> I merged the functions.
> Stuff is supposed to work asif there is arbitrary inlining.
> At least until/unless we get a pragma to mark a function as not inlinable or a direct language feature analogous to "volatile" to preserve locals -- currently inserting try does it but that's an implementation detail I think
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091109/45864cb7/attachment-0002.html>