Issue 3342 in pharo: have a look at sharedQueue fixes from Levente

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Issue 3342 in pharo: have a look at sharedQueue fixes from Levente

pharo
Status: Accepted
Owner: stephane.ducasse
Labels: Milestone-1.3 Type-Squeak

New issue 3342 by stephane.ducasse: have a look at sharedQueue fixes from  
Levente
http://code.google.com/p/pharo/issues/detail?id=3342

Check the squeak mailing:
the thread of 15 of november 2010: [squeak-dev] The Trunk: Kernel-ul.515.mcz





     Hi Folks,

     Please also restore Semaphore>>critical:ifLocked: It already includes  
this comment: "Note: The following is tricky and depends on the fact that  
the VM will not switch between processes while executing byte codes  
(process switches happen only in real sends). The following test is written  
carefully so that it will result in bytecodes only."

     To be more explicit, in Cuis it also says: "Do not change the following  
#== for #=, as #== is not a real message send, just a bytecode."


It's unnecessary, because #= also has it's own bytecode in the current VM.  
So #= won't be a real message send in this case, because both excessSignals  
and 0 are SmallIntegers.

Also, this method has a bug. There's no guarantee, that the sender won't  
wait for the semaphore. I uploaded a fix to the Inbox for review recently,  
though I didn't get any feedback on it:  
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-November/155058.html



Reply | Threaded
Open this post in threaded view
|

Re: Issue 3342 in pharo: have a look at sharedQueue fixes from Levente

pharo
Updates:
        Status: Invalid

Comment #1 on issue 3342 by [hidden email]: have a look at  
sharedQueue fixes from Levente
http://code.google.com/p/pharo/issues/detail?id=3342

SharedQueue was replaced by SharedQueue2 in Pharo