TimedPromise continues forever

When a TimedPromise times out, the block it was running continues to run. How do you stop the block?

promise := [[1] repeat] timedPromiseFor: 5000 at: 47.

[[promise value] on: Protocols.PromiseExpiredError do: [:ex | ex return: nil]] fork

There doesn’t seem to be a path from the promise to the process running the block.

Steve

PS A hack to kill the process from the example above - (Processor processesAt: 47) do: #terminate

Steve,

I'm guessing you'll find the block never got started. Refer to the attached discussion "A useful Promise" started 2010.04.14.

A ratchet semaphore is a direct way to address it and can use lower priority promises.

Paul Baumann

When a TimedPromise times out, the block it was running continues to run. How do you stop the block?

promise := [[1] repeat] timedPromiseFor: 5000 at: 47.

[[promise value] on: Protocols.PromiseExpiredError do: [:ex | ex return: nil]] fork

There doesn’t seem to be a path from the promise to the process running the block.

Steve

PS A hack to kill the process from the example above - (Processor processesAt: 47) do: #terminate

Paul,

The block gets started: I’m running this in a workspace so it gets sent #value immediately. The problem isn’t the starting, it’s the stopping :-).

I had my own homegrown code that used Delay and its semaphore, and terminated the block on timeout. However, it didn’t take care of passing exceptions from the child process to the parent, so I tried moving to TimedPromise. I was surprised that the default behavior wasn’t just to terminate the process at the timeout. Duration>>toFinish:orElse: and BlockClosure>>toolSafeIn:else: are similar to what I want in terms of terminating the runaway process, but don’t pass exceptions to the parent.

I suppose I need to make BlockClosure>>timedPromise… pass the new process to the promise, so that on timeout it at least has the information it needs.

Thanks for the pointer to your ratchet/deferable idea. I don’t need that myself, since I send value immediately anyway. As my promise blocks are at a lower priority, adding the ratchet just makes flow jump to the subprocess to run the #signal, which sends it back to the main process, and then my #value would send it back to the subprocess. If that analysis is right, I guess the ratchet is only useful if the subprocess is at the same priority?

Steve

I’ve published TimeLimitedPromise in the public store:

TimeLimitedPromise evaluates a block in a lower-priority subprocess, with a timeout. It has the ability to pass subprocess errors to the parent process, like Promise, and a timeout like TimedPromise. On timeout, it too raises PromiseExpiredError, but also first terminates the subprocess (any unwind blocks there are run, but you should still be careful that termination does not leave objects in a bad state).

Share and enjoy! (corrections welcome)

Steve

Steven,

How do you feel about the below patch to ensure that one can get the stack of promise’d process in the exception dump when the PromiseExpiredError is handled (via Process>>printStackOn: or RuntimeFullDumper>>dumpSuspendedProcesses)?

TimeLimitedPromise>>value

                delay wait.          "Wait for data arrival or alarm expiry."

                delay disable.

                sync signal.         "To allow multiple reads of the result"

                ^exception == nil

                                ifTrue:

                                                [hasValue

                                                                ifTrue: [value]

                                                                ifFalse:

                                                                                [process suspend.

                                                                                [self signalTimeout] ensure: [process terminate]]]

                                ifFalse:

                                                [exception

                                                                copyForReraise;

                                                                searchFrom: thisContext;

                                                                raise].

-Boris

I’ve published TimeLimitedPromise in the public store:

TimeLimitedPromise evaluates a block in a lower-priority subprocess, with a timeout. It has the ability to pass subprocess errors to the parent process, like Promise, and a timeout like TimedPromise. On timeout, it too raises PromiseExpiredError, but also first terminates the subprocess (any unwind blocks there are run, but you should still be careful that termination does not leave objects in a bad state).

Share and enjoy! (corrections welcome)

Steve

[([(2 ** 100) factorial] timeLimitedPromiseFor: 500

                at: Processor userSchedulingPriority - 1) value]

                                on: PromiseExpiredError

                                do: [:ex | ex return: (String streamContents: [:ws | ex parameter process printStackOn: ws])]

LargePositiveInteger(LargeInteger)>>*

LargePositiveInteger(Integer)>>factorial

optimized [] in [] in UndefinedObject>>unboundMethod

optimized [] in [] in [] in BlockClosure>>promiseBlock:

BlockClosure>>on:do:

optimized [] in [] in BlockClosure>>promiseBlock:

BlockClosure>>on:do:

optimized [] in BlockClosure>>promiseBlock:

BlockClosure>>on:do:

optimized [] in Process class>>forBlock:priority:

Steven,

How do you feel about the below patch to ensure that one can get the stack of promise’d process in the exception dump when the PromiseExpiredError is handled (via Process>>printStackOn: or RuntimeFullDumper>>dumpSuspendedProcesses)?

TimeLimitedPromise>>value

                delay wait.          "Wait for data arrival or alarm expiry."

                delay disable.

                sync signal.         "To allow multiple reads of the result"

                ^exception == nil

                                ifTrue:

                                                [hasValue

                                                                ifTrue: [value]

                                                                ifFalse:

                                                                                [process suspend.

                                                                                [self signalTimeout] ensure: [process terminate]]]

                                ifFalse:

                                                [exception

                                                                copyForReraise;

                                                                searchFrom: thisContext;

                                                                raise].

-Boris

I’ve published TimeLimitedPromise in the public store:

TimeLimitedPromise evaluates a block in a lower-priority subprocess, with a timeout. It has the ability to pass subprocess errors to the parent process, like Promise, and a timeout like TimedPromise. On timeout, it too raises PromiseExpiredError, but also first terminates the subprocess (any unwind blocks there are run, but you should still be careful that termination does not leave objects in a bad state).

Share and enjoy! (corrections welcome)

Steve

Mind you, similar result could be obtained explicitly even when the process was terminated prior to signal, but the benefit of suspending and then terminating is that default RTP dumper will log suspended processes, but not terminated ones.

[([(2 ** 100) factorial] timeLimitedPromiseFor: 500

                at: Processor userSchedulingPriority - 1) value]

                                on: PromiseExpiredError

                                do: [:ex | ex return: (String streamContents: [:ws | ex parameter process printStackOn: ws])]

optimized [] in [] in Process>>terminate

LargePositiveInteger(LargeInteger)>>*

LargePositiveInteger(Integer)>>factorial

optimized [] in [] in UndefinedObject>>unboundMethod

optimized [] in [] in [] in BlockClosure>>promiseBlock:

BlockClosure>>on:do:

optimized [] in [] in BlockClosure>>promiseBlock:

BlockClosure>>on:do:

optimized [] in BlockClosure>>promiseBlock:

BlockClosure>>on:do:

optimized [] in Process class>>forBlock:priority:

[([(2 ** 100) factorial] timeLimitedPromiseFor: 500

                at: Processor userSchedulingPriority - 1) value]

                                on: PromiseExpiredError

                                do: [:ex | ex return: (String streamContents: [:ws | ex parameter process printStackOn: ws])]

LargePositiveInteger(LargeInteger)>>*

LargePositiveInteger(Integer)>>factorial

optimized [] in [] in UndefinedObject>>unboundMethod

optimized [] in [] in [] in BlockClosure>>promiseBlock:

BlockClosure>>on:do:

optimized [] in [] in BlockClosure>>promiseBlock:

BlockClosure>>on:do:

optimized [] in BlockClosure>>promiseBlock:

BlockClosure>>on:do:

optimized [] in Process class>>forBlock:priority:

Steven,

How do you feel about the below patch to ensure that one can get the stack of promise’d process in the exception dump when the PromiseExpiredError is handled (via Process>>printStackOn: or RuntimeFullDumper>>dumpSuspendedProcesses)?

TimeLimitedPromise>>value

                delay wait.          "Wait for data arrival or alarm expiry."

                delay disable.

                sync signal.         "To allow multiple reads of the result"

                ^exception == nil

                                ifTrue:

                                                [hasValue

                                                                ifTrue: [value]

                                                                ifFalse:

                                                                                [process suspend.

                                                                                [self signalTimeout] ensure: [process terminate]]]

                                ifFalse:

                                                [exception

                                                                copyForReraise;

                                                                searchFrom: thisContext;

                                                                raise].

-Boris

I’ve published TimeLimitedPromise in the public store:

TimeLimitedPromise evaluates a block in a lower-priority subprocess, with a timeout. It has the ability to pass subprocess errors to the parent process, like Promise, and a timeout like TimedPromise. On timeout, it too raises PromiseExpiredError, but also first terminates the subprocess (any unwind blocks there are run, but you should still be careful that termination does not leave objects in a bad state).

Share and enjoy! (corrections welcome)

Steve