Process Tests and
Locked
 
Administrator
|
I was reading the Blue Book chapter on processes and figured I'd turn it into tests...
Issue 6009: Improved ProcessTest http://code.google.com/p/pharo/issues/detail?id=6009 During the process, I noticed that the Blue Book specifies that #fork returns the block itself (pg. 252), while in Pharo it returns the process (see #testFork in the slice). Should our implementation be changed to match the Blue Book? Thanks, Sean
Cheers,
Sean |
|
Administrator
|
The thread title should've been "... and #fork return value"
Cheers,
Sean |
|
|
In reply to this post by Sean P. DeNigris
Hi Sean:
On 02 Jun 2012, at 05:07, Sean P. DeNigris wrote: > During the process, I noticed that the Blue Book specifies that #fork > returns the block itself (pg. 252), while in Pharo it returns the process > (see #testFork in the slice). Should our implementation be changed to match > the Blue Book? Why would it be desirable to have the block? How would you obtain the process object after your change? Having the process directly is useful to do fork/join style operations. 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 |
|
|
On 2 June 2012 10:28, Stefan Marr <[hidden email]> wrote:
> Hi Sean: > > On 02 Jun 2012, at 05:07, Sean P. DeNigris wrote: > >> During the process, I noticed that the Blue Book specifies that #fork >> returns the block itself (pg. 252), while in Pharo it returns the process >> (see #testFork in the slice). Should our implementation be changed to match >> the Blue Book? > > Why would it be desirable to have the block? > How would you obtain the process object after your change? > by using #newProcess. using the return value of fork provokes you to write incorrect concurrent code. for instance, i found once, some code which assumes that forked process not yet started, or not yet terminated, and people trying to do something with process immediately after issuing #fork. > Having the process directly is useful to do fork/join style operations. > > 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 > > -- Best regards, Igor Stasenko. |
|
|
On 02 Jun 2012, at 11:07, Igor Stasenko wrote: > On 2 June 2012 10:28, Stefan Marr <[hidden email]> wrote: >> Hi Sean: >> >> On 02 Jun 2012, at 05:07, Sean P. DeNigris wrote: >> >>> During the process, I noticed that the Blue Book specifies that #fork >>> returns the block itself (pg. 252), while in Pharo it returns the process >>> (see #testFork in the slice). Should our implementation be changed to match >>> the Blue Book? >> >> Why would it be desirable to have the block? > >> How would you obtain the process object after your change? >> > by using #newProcess. > > using the return value of fork provokes you to write incorrect concurrent code. > for instance, i found once, some code which assumes that forked > process not yet started, > or not yet terminated, and people trying to do something with process > immediately after issuing #fork. So, just because somebody made a mistake, the whole thing is not worthwhile anymore? What is the value of having the direct reference to the block? What are you going to do with it? I would buy an argument that #fork should return a promise (or you can call it future if you like) to the return value of the block. I don't see how the block itself would be of any use. I do see however, that the block (i.e., self) was returned in earlier versions just because of convention, and no further thought. [Some people claim that the whole idea of Process in Smalltalk was never fully thought out anyway. (And that's not me.)] 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 |
|
|
On 2 June 2012 11:40, Stefan Marr <[hidden email]> wrote:
> > On 02 Jun 2012, at 11:07, Igor Stasenko wrote: > >> On 2 June 2012 10:28, Stefan Marr <[hidden email]> wrote: >>> Hi Sean: >>> >>> On 02 Jun 2012, at 05:07, Sean P. DeNigris wrote: >>> >>>> During the process, I noticed that the Blue Book specifies that #fork >>>> returns the block itself (pg. 252), while in Pharo it returns the process >>>> (see #testFork in the slice). Should our implementation be changed to match >>>> the Blue Book? >>> >>> Why would it be desirable to have the block? >> >>> How would you obtain the process object after your change? >>> >> by using #newProcess. >> >> using the return value of fork provokes you to write incorrect concurrent code. >> for instance, i found once, some code which assumes that forked >> process not yet started, >> or not yet terminated, and people trying to do something with process >> immediately after issuing #fork. > > So, just because somebody made a mistake, the whole thing is not worthwhile anymore? > What is the value of having the direct reference to the block? > What are you going to do with it? > > I would buy an argument that #fork should return a promise (or you can call it future if you like) to the return value of the block. > > I don't see how the block itself would be of any use. agreed. I didn't said that returning block has any value.. just noted that returning a process is not much more valuable. Because there is a good chances that the process which you get is already terminated :) > I do see however, that the block (i.e., self) was returned in earlier versions just because of convention, and no further thought. > [Some people claim that the whole idea of Process in Smalltalk was never fully thought out anyway. (And that's not me.)] > > 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 > > -- Best regards, Igor Stasenko. |
|
|
On 2 June 2012 12:24, Igor Stasenko <[hidden email]> wrote:
> On 2 June 2012 11:40, Stefan Marr <[hidden email]> wrote: >> >> On 02 Jun 2012, at 11:07, Igor Stasenko wrote: >> >>> On 2 June 2012 10:28, Stefan Marr <[hidden email]> wrote: >>>> Hi Sean: >>>> >>>> On 02 Jun 2012, at 05:07, Sean P. DeNigris wrote: >>>> >>>>> During the process, I noticed that the Blue Book specifies that #fork >>>>> returns the block itself (pg. 252), while in Pharo it returns the process >>>>> (see #testFork in the slice). Should our implementation be changed to match >>>>> the Blue Book? >>>> >>>> Why would it be desirable to have the block? >>> >>>> How would you obtain the process object after your change? >>>> >>> by using #newProcess. >>> >>> using the return value of fork provokes you to write incorrect concurrent code. >>> for instance, i found once, some code which assumes that forked >>> process not yet started, >>> or not yet terminated, and people trying to do something with process >>> immediately after issuing #fork. >> >> So, just because somebody made a mistake, the whole thing is not worthwhile anymore? >> What is the value of having the direct reference to the block? >> What are you going to do with it? >> >> I would buy an argument that #fork should return a promise (or you can call it future if you like) to the return value of the block. >> >> I don't see how the block itself would be of any use. > > agreed. > I didn't said that returning block has any value.. just noted that > returning a process is not much more valuable. Because there is a good > chances that the process which you get is already terminated :) And handily, in this case returning a Promise/Future means you... simply get the resolved value! frank >> I do see however, that the block (i.e., self) was returned in earlier versions just because of convention, and no further thought. >> [Some people claim that the whole idea of Process in Smalltalk was never fully thought out anyway. (And that's not me.)] >> >> 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 >> >> > > > > -- > Best regards, > Igor Stasenko. > |
|
|
In reply to this post by Stefan Marr-3
On 2 June 2012 09:28, Stefan Marr <[hidden email]> wrote:
> Hi Sean: > > On 02 Jun 2012, at 05:07, Sean P. DeNigris wrote: > >> During the process, I noticed that the Blue Book specifies that #fork >> returns the block itself (pg. 252), while in Pharo it returns the process >> (see #testFork in the slice). Should our implementation be changed to match >> the Blue Book? > > Why would it be desirable to have the block? > How would you obtain the process object after your change? > > Having the process directly is useful to do fork/join style operations. How do you #join Processes? I can't see anything in Process' protocol for doing so. so what am I missing? 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 > > |
|
|
On Wed, Jun 13, 2012 at 7:35 AM, Frank Shearar <[hidden email]> wrote:
Nothing. Theres no support for join. You have to roll your own.
best, Eliot |
|
|
On 13 June 2012 23:15, Eliot Miranda <[hidden email]> wrote:
> > > On Wed, Jun 13, 2012 at 7:35 AM, Frank Shearar <[hidden email]> > wrote: >> >> On 2 June 2012 09:28, Stefan Marr <[hidden email]> wrote: >> > Hi Sean: >> > >> > On 02 Jun 2012, at 05:07, Sean P. DeNigris wrote: >> > >> >> During the process, I noticed that the Blue Book specifies that #fork >> >> returns the block itself (pg. 252), while in Pharo it returns the >> >> process >> >> (see #testFork in the slice). Should our implementation be changed to >> >> match >> >> the Blue Book? >> > >> > Why would it be desirable to have the block? >> > How would you obtain the process object after your change? >> > >> > Having the process directly is useful to do fork/join style operations. >> >> 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. 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]. frank >> >> >> 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 >> > >> > >> > > > > -- > best, > Eliot > |
|
|
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. 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 |
|
|
On 14 June 2012 11:42, Stefan Marr <[hidden email]> 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 > > |
|
|
In reply to this post by Frank Shearar-3
On Thu, Jun 14, 2012 at 2:34 AM, Frank Shearar <[hidden email]> wrote: On 13 June 2012 23:15, Eliot Miranda <[hidden email]> wrote: Sorry to reply so late. I think the blue book definition is broken. fork should answer the process. It has been changed to do so in VisualWorks for a long time. I think the blue book definition is simply a bug. It can easily be implemented in the caller using yourself, i.e.
[...] fork; yourself answers the block if one needs it. >> > best, Eliot |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |