On 14 June 2012 11:42, Stefan Marr <smalltalk@stefan-marr.de> 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