Make WAGemStoneServiceTask>>value block until a result is ready

Hi -


In a seaside 3.0.2 app I'm porting to Gemstone 2.4.4.1 I've been using
Ramon Leon's/Nick Ager's PharoFutures implementation in Pharo.  I'm
trying to figure out how to port those parts to Gemstone.

   I  haven't (yet) had a need to do a polling/non-blocking call to the
future to see if it has a value.  In an attempt to make #value a
blocking call I changed these:

WAGemStoneServiceTask>>value
        self hasValue ifFalse:[self processTask].
        ^ taskValue

And

WAGemStoneServiceTask>>processTask
        | value |
        self performSafely: [ value := taskBlock value ].

        GRPlatform current doTransaction: [
                taskValue := value.
                hasValue := true.
                self class inProcess remove: self ifAbsent:[]]


which definitely returns a value, but I'm not sure if it is an effective
solution to my problem.  It seems to work OK but I don't know what other
demons I may have created.  Is there anything obviously wrong with this
approach?


Thanks.

Paul

Paul,

I'll have to refresh my memory on the service task code ... probably
tomorrow...

Dale

On 12/09/2010 01:50 PM, Paul DeBruicker wrote:

Paul,

I think that you want to be using WAGemStoneFuture from
Seaside-GemStone-ServiceTask in
http://seaside.gemstone.com/ss/Seaside30...I'm adding that package to
Seaside3.0.3 configuration, but you can load it manually into
Seaside3.0.2 and it should work.

Nick created a MockGemStone-ServiceTask package in
http://seaside.gemstone.com/ss/MockGemStone that provides a pharo
implementation for WAGemStoneFuture. I'm building a configuration for
MockGemStone as we speak.

I think that Nick worked out most of the kinks ... one of the things
that I remember is that you do have to poll using hasValue, since the
main reason for using the WAGemStoneFuture is that you don't want the
session to block while waiting for the task to finish.

Dale

On 12/09/2010 01:50 PM, Paul DeBruicker wrote: