On 14 June 2012 11:42, Stefan Marr <[email protected]> wrote: > Hi: > > On 14 Jun 2012, at 11:34, Frank Shearar wrote: > >>>> How do you #join Processes? I can't see anything in Process' protocol >>>> for doing so. so what am I missing? >>> >>> >>> Nothing. Theres no support for join. You have to roll your own. >> >> OK, that's what I thought. Stefan's comment intrigued me. > > Yes, my fault. I added it to some random subclass somewhere, because I > thought it was handy. > It is indeed not in the standard images. > > >> >> It would be kind've handy to be able to say - even though we don't use >> native threads - something like this: >> >> (0..10).map {|i| >> Thread.new { sleep(1); i } >> }.map {|t| t.value} >> >> only in a decent language: >> >> ((0 to: 10) >> collect: [:i | [(Delay forSeconds: 1) wait. i] fork]) >> collect: [:p | p value]. > > Yes, that was part of the discussion. > > For the options discussed of the return value of fork, we have three options: > > 1. self [Smalltalk-80 defines it this way, apparently] > self is the block, > it is the consistent return value for methods without real return value. > > -> I think, this is the least useful option > > 2. Process [current implementation] > It's the object created as the side-effect of fork. > Allows to query whether the fork already completed. > Process could be extended to offer #join (at a cost of a semaphore, > presumably). > > 3. Promise > As the placeholder for the result value of the block computation. > Benefit is that we get an immediate handle on the result, and the > ability to wait for the completion of the process, even if we only > care for its side-effects. > > There is however currently no Promise class in Pharo. Squeak got one, I > think.
Yes. Also, this mention of Promise made me start to dig into Promise and Squeak's implementation of futures. That lead me back to asking the above! What I find confusing is that I don't see how a Process can return anything. I mean, in the sense that a Process is an undelimited continuation it doesn't _have_ a return type, but we can pretend for a moment that they do, or can, return. I see no way of getting that return value. Ruby's Thread#value simply waits for the thread to terrminate, and returns the value of the last expression. A bit like a block, actually. Given the long-standing behaviour of #fork (hence many out-of-image packages using it), it seems prudent to have a _new_ API for fork/join. That new API could quite happily use Promises for both forking and joining. frank > Best regards > Stefan > > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > >
