<br><br><div class="gmail_quote">On Dec 21, 2007 10:41 AM, Igor Stasenko <<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On 20/12/2007, Michael van der Gulik <<a href="mailto:mikevdg@gmail.com">mikevdg@gmail.com</a>> wrote:<br>><br>><br>> On Dec 21, 2007 8:09 AM, Igor Stasenko <<a href="mailto:siguctua@gmail.com">
siguctua@gmail.com</a>> wrote:<br>> ><br>> > On 20/12/2007, Tom Phoenix <<a href="mailto:rootbeer@redcat.com">rootbeer@redcat.com</a>> wrote:<br>> > > On 12/20/07, Igor Stasenko <<a href="mailto:siguctua@gmail.com">
siguctua@gmail.com</a>> wrote:<br>> > ><br>> > > > This is essentially useful when you need to guarantee that process<br>> > > > will stay suspended even if it's currently suspended waiting for
<br>> > > > semaphore signal.<br>> > ><br>> > > Do you mean to say that your processes resume running before their<br>> > > semaphores are signaled?<br>> > ><br>> ><br>
> > Just try to run given code:<br>> ><br>> > | sema proc |<br>> > sema := Semaphore new.<br>> > proc := [ sema critical: [ Transcript show: 'Oopsie' ] ] fork.<br>> > Processor yield.
<br>> > proc suspend.<br>> > proc resume.<br>> ><br><snip><br></div>No, i'm specially doing Processor yield to make proc start waiting for<br>semaphore.</blockquote><div><br>Er... oh, I see. From my point of view (which consists of little format training wrt Process management), you're mis-treating these poor objects. The code would work... but I'd never write code like that.
<br><br>If you want to use #critical:, you should be making the Semaphore with "sema := Semaphore forMutualExclusion".<br><br>"Processor yield" shouldn't ever be used IMHO. It relies on particular behaviour of the scheduler. In a future version of Squeak when we properly support pthreads or we "improve" the behaviour of the scheduler, your code might not work as expected.
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>> I can't try this code at the moment - I don't have Squeak nearby.
<br>><br>> Generally, I'd rarely use Process>>suspend in my code. Semaphores provide<br>> the behaviour that you want; a Semaphore is a linked list of waiting<br>> processes. When you call #wait on a semaphore, your process gets added to
<br>> the list. When you call #signal, the process at one of the ends of the list<br>> (FIFO? LIFO? Can't remember) gets resumed. The effect of #suspend and<br>> #resume should have no effect on the signalled/waiting state of a Process.
<br>><br>> In the Launcher example that you give, it would be okay to use #suspend and<br>> #resume, but there shouldn't be anything else in the image which is trying<br>> to suspend or resume those processes.
<br>><br></div>Yes, i was using it like:<br><br>suspendedList := OrderedCollection new.<br>(Process allInstances select:[:proc | proc isActiveProcess not and: [<br>proc isSuspended not ]]) do: [:proc | suspendedList add: proc. proc
<br>suspend].<br><br><... do my code...><br><br>suspendedList do: [:proc | proc resume ].<br><br>But because of semaphores bug, after i sending #resume to processes<br>which waiting on semaphore signal causing them think that signal is
<br>received.<br>Btw you can try this code yourself and see how low space watcher pops<br>up scaring you to death :)<br></blockquote></div><br><br>I'll try this when I get home. I do a lot of multithreaded programming in Squeak so its important to me that this stuff works right.
<br><br>Gulik.<br clear="all"><br>-- <br><a href="http://people.squeakfoundation.org/person/mikevdg">http://people.squeakfoundation.org/person/mikevdg</a><br><a href="http://gulik.pbwiki.com/">http://gulik.pbwiki.com/</a>