What is the best way to arrange for a notification when a given process
terminates, naturally or otherwise? I've tried the following but it never results in anything: block := [10 timesRepeat: [(Delay forMilliseconds: 100) wait. Transcript show: '.']]. [block forkAt: 10] on: Process terminateSignal do: [:ex| Transcript show: 'done.']. In fact I can't figure out that the terminateSignal is good for since it is always caught when a process is created on a block: forBlock: aBlock priority: anInteger | newProcess | newProcess := self new. newProcess suspendedContext: [aBlock on: Process terminateSignal do: [:ex | ex return]. Processor activeProcess primTerminate] newContext. newProcess priority: anInteger. ^newProcess ----- Joerg Beekmann DeepCove Labs 4th floor 595 Howe Street Vancouver, BC, V6C 2T5 voice +1.604.689.0322 fax +1.604.689.0311 [hidden email] CONFIDENTIALITY NOTICE Unless otherwise indicated this email contains information that is private and confidential. If you have received it in error, please notify the sender and delete this message along with any attachments. |
If you control the spawning of the process, just do
[block forkAt: 10] ensure: [Transcript show: 'done']. If you only want to know if it terminates unnaturally, ifCurtailed: should do it. At 04:26 PM 10/12/2006, Joerg Beekmann wrote: >What is the best way to arrange for a notification when a given process >terminates, naturally or otherwise? I've tried the following but it >never results in anything: > >block := [10 timesRepeat: [(Delay forMilliseconds: 100) wait. Transcript >show: '.']]. >[block forkAt: 10] > on: Process terminateSignal > do: [:ex| Transcript show: 'done.']. > >In fact I can't figure out that the terminateSignal is good for since it >is always caught when a process is created on a block: > >forBlock: aBlock priority: anInteger > | newProcess | > newProcess := self new. > newProcess suspendedContext: > [aBlock > on: Process terminateSignal > do: [:ex | ex return]. > Processor activeProcess primTerminate] newContext. > newProcess priority: anInteger. > ^newProcess > >----- >Joerg Beekmann >DeepCove Labs >4th floor 595 Howe Street >Vancouver, BC, V6C 2T5 >voice +1.604.689.0322 >fax +1.604.689.0311 >[hidden email] > > >CONFIDENTIALITY NOTICE >Unless otherwise indicated this email contains information that is >private >and confidential. If you have received it in error, please notify the >sender >and delete this message along with any attachments. -- Alan Knight [|], Cincom Smalltalk Development [hidden email] [hidden email] http://www.cincom.com/smalltalk "The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross |
In reply to this post by Joerg Beekmann, DeepCove Labs (YVR)
When I want to synchronize with a finishing process, I usually just make
it signal a semaphore as the last thing it does. Then I can wait on that semaphore in the other process. The terminate signal is used to terminate process while it's executing, not when it finishes normally. Modeling it as an exception allows to reuse exception unwinding for proper behavior of #ensure: blocks in the face of process termination. HTH, Martin Joerg Beekmann wrote: > What is the best way to arrange for a notification when a given process > terminates, naturally or otherwise? I've tried the following but it > never results in anything: > > block := [10 timesRepeat: [(Delay forMilliseconds: 100) wait. Transcript > show: '.']]. > [block forkAt: 10] > on: Process terminateSignal > do: [:ex| Transcript show: 'done.']. > > In fact I can't figure out that the terminateSignal is good for since it > is always caught when a process is created on a block: > > forBlock: aBlock priority: anInteger > | newProcess | > newProcess := self new. > newProcess suspendedContext: > [aBlock > on: Process terminateSignal > do: [:ex | ex return]. > Processor activeProcess primTerminate] newContext. > newProcess priority: anInteger. > ^newProcess > > ----- > Joerg Beekmann > DeepCove Labs > 4th floor 595 Howe Street > Vancouver, BC, V6C 2T5 > voice +1.604.689.0322 > fax +1.604.689.0311 > [hidden email] > > > CONFIDENTIALITY NOTICE > Unless otherwise indicated this email contains information that is > private > and confidential. If you have received it in error, please notify the > sender > and delete this message along with any attachments. > > |
In reply to this post by Alan Knight-2
That doesn't cover natural termination:
[[(Delay forSeconds: 2) wait. Transcript show: 'work done'] forkAt: 10] ensure: [Transcript show: 'forked']. Try using a semaphore: | sem | sem := Semaphore new. [sem wait. Transcript show: 'work done'] forkAt: 10. [[(Delay forSeconds: 2) wait] ensure: [sem signal]] forkAt: 10. Transcript show: 'forked'. Dave Alan Knight wrote: > If you control the spawning of the process, just do > [block forkAt: 10] ensure: [Transcript show: 'done']. > > If you only want to know if it terminates unnaturally, ifCurtailed: should do it. > > At 04:26 PM 10/12/2006, Joerg Beekmann wrote: >> What is the best way to arrange for a notification when a given process >> terminates, naturally or otherwise? I've tried the following but it >> never results in anything: >> >> block := [10 timesRepeat: [(Delay forMilliseconds: 100) wait. Transcript >> show: '.']]. >> [block forkAt: 10] >> on: Process terminateSignal >> do: [:ex| Transcript show: 'done.']. >> >> In fact I can't figure out that the terminateSignal is good for since it >> is always caught when a process is created on a block: >> >> forBlock: aBlock priority: anInteger >> | newProcess | >> newProcess := self new. >> newProcess suspendedContext: >> [aBlock >> on: Process terminateSignal >> do: [:ex | ex return]. >> Processor activeProcess primTerminate] newContext. >> newProcess priority: anInteger. >> ^newProcess >> >> ----- >> Joerg Beekmann >> DeepCove Labs >> 4th floor 595 Howe Street >> Vancouver, BC, V6C 2T5 >> voice +1.604.689.0322 >> fax +1.604.689.0311 >> [hidden email] >> >> >> CONFIDENTIALITY NOTICE >> Unless otherwise indicated this email contains information that is >> private >> and confidential. If you have received it in error, please notify the >> sender >> and delete this message along with any attachments. > > -- > Alan Knight [|], Cincom Smalltalk Development > [hidden email] > [hidden email] > http://www.cincom.com/smalltalk > > "The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross > > |
Ahem. I meant that it doesn't tell you when the forked process
completes, only when the *forking* of the process completes... Dave Stevenson wrote: > That doesn't cover natural termination: > > [[(Delay forSeconds: 2) wait. > Transcript show: 'work done'] > forkAt: 10] > ensure: [Transcript show: 'forked']. > > Try using a semaphore: > > | sem | > sem := Semaphore new. > > [sem wait. > Transcript show: 'work done'] forkAt: 10. > > [[(Delay forSeconds: 2) wait] ensure: [sem signal]] > forkAt: 10. > > Transcript show: 'forked'. > > Dave > > Alan Knight wrote: >> If you control the spawning of the process, just do >> [block forkAt: 10] ensure: [Transcript show: 'done']. >> >> If you only want to know if it terminates unnaturally, ifCurtailed: >> should do it. >> >> At 04:26 PM 10/12/2006, Joerg Beekmann wrote: >>> What is the best way to arrange for a notification when a given process >>> terminates, naturally or otherwise? I've tried the following but it >>> never results in anything: >>> >>> block := [10 timesRepeat: [(Delay forMilliseconds: 100) wait. Transcript >>> show: '.']]. >>> [block forkAt: 10] >>> on: Process terminateSignal >>> do: [:ex| Transcript show: 'done.']. >>> >>> In fact I can't figure out that the terminateSignal is good for since it >>> is always caught when a process is created on a block: >>> >>> forBlock: aBlock priority: anInteger | newProcess | >>> newProcess := self new. >>> newProcess suspendedContext: >>> [aBlock >>> on: Process terminateSignal >>> do: [:ex | ex return]. >>> Processor activeProcess primTerminate] newContext. >>> newProcess priority: anInteger. >>> ^newProcess >>> >>> ----- >>> Joerg Beekmann >>> DeepCove Labs >>> 4th floor 595 Howe Street >>> Vancouver, BC, V6C 2T5 >>> voice +1.604.689.0322 >>> fax +1.604.689.0311 >>> [hidden email] >>> >>> >>> CONFIDENTIALITY NOTICE >>> Unless otherwise indicated this email contains information that is >>> private >>> and confidential. If you have received it in error, please notify the >>> sender >>> and delete this message along with any attachments. >> >> -- >> Alan Knight [|], Cincom Smalltalk Development >> [hidden email] >> [hidden email] >> http://www.cincom.com/smalltalk >> >> "The Static Typing Philosophy: Make it fast. Make it right. Make it >> run." - Niall Ross >> >> > |
Doh! I meant to write it as
[block ensure: [Transcript show: 'done']] forkAt: 10. At 05:20 PM 10/12/2006, Dave Stevenson wrote: >Ahem. I meant that it doesn't tell you when the forked process completes, only when the *forking* of the process completes... > >Dave Stevenson wrote: >>That doesn't cover natural termination: >> [[(Delay forSeconds: 2) wait. >> Transcript show: 'work done'] >> forkAt: 10] >> ensure: [Transcript show: 'forked']. >>Try using a semaphore: >> | sem | >> sem := Semaphore new. >> [sem wait. >> Transcript show: 'work done'] forkAt: 10. >> [[(Delay forSeconds: 2) wait] ensure: [sem signal]] >> forkAt: 10. >> Transcript show: 'forked'. >>Dave >>Alan Knight wrote: >>>If you control the spawning of the process, just do >>> [block forkAt: 10] ensure: [Transcript show: 'done']. >>> >>>If you only want to know if it terminates unnaturally, ifCurtailed: should do it. >>> >>>At 04:26 PM 10/12/2006, Joerg Beekmann wrote: >>>>What is the best way to arrange for a notification when a given process >>>>terminates, naturally or otherwise? I've tried the following but it >>>>never results in anything: >>>> >>>>block := [10 timesRepeat: [(Delay forMilliseconds: 100) wait. Transcript >>>>show: '.']]. >>>>[block forkAt: 10] >>>> on: Process terminateSignal >>>> do: [:ex| Transcript show: 'done.']. >>>> >>>>In fact I can't figure out that the terminateSignal is good for since it >>>>is always caught when a process is created on a block: >>>> >>>>forBlock: aBlock priority: anInteger | newProcess | >>>> newProcess := self new. >>>> newProcess suspendedContext: >>>> [aBlock >>>> on: Process terminateSignal >>>> do: [:ex | ex return]. >>>> Processor activeProcess primTerminate] newContext. >>>> newProcess priority: anInteger. >>>> ^newProcess >>>> >>>>----- >>>>Joerg Beekmann >>>>DeepCove Labs >>>>4th floor 595 Howe Street >>>>Vancouver, BC, V6C 2T5 >>>>voice +1.604.689.0322 >>>>fax +1.604.689.0311 >>>>[hidden email] >>>> >>>> >>>>CONFIDENTIALITY NOTICE >>>>Unless otherwise indicated this email contains information that is >>>>private >>>>and confidential. If you have received it in error, please notify the >>>>sender >>>>and delete this message along with any attachments. >>> >>>-- >>>Alan Knight [|], Cincom Smalltalk Development >>>[hidden email] >>>[hidden email] >>>http://www.cincom.com/smalltalk >>> >>>"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross >>> -- Alan Knight [|], Cincom Smalltalk Development [hidden email] [hidden email] http://www.cincom.com/smalltalk "The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross |
In reply to this post by Dave Stevenson-2
The schemes suggested will work when I'm creating the process, as I was
in my example. But in my case I don't have control over the creation of the process. So restating the question: given an arbitrary process, can I arrange to be informed when the process ends? Joerg ----- Joerg Beekmann DeepCove Labs 4th floor 595 Howe Street Vancouver, BC, V6C 2T5 voice +1.604.689.0322 fax +1.604.689.0311 [hidden email] CONFIDENTIALITY NOTICE Unless otherwise indicated this email contains information that is private and confidential. If you have received it in error, please notify the sender and delete this message along with any attachments. > -----Original Message----- > From: Dave Stevenson [mailto:[hidden email]] > Sent: October 12, 2006 2:17 PM > To: Alan Knight > Cc: Joerg Beekmann; vwnc-list > Subject: Re: How to be informed when a process terminates > > That doesn't cover natural termination: > > [[(Delay forSeconds: 2) wait. > Transcript show: 'work done'] > forkAt: 10] > ensure: [Transcript show: 'forked']. > > Try using a semaphore: > > | sem | > sem := Semaphore new. > > [sem wait. > Transcript show: 'work done'] forkAt: 10. > > [[(Delay forSeconds: 2) wait] ensure: [sem signal]] > forkAt: 10. > > Transcript show: 'forked'. > > Dave > > Alan Knight wrote: > > If you control the spawning of the process, just do > > [block forkAt: 10] ensure: [Transcript show: 'done']. > > > > If you only want to know if it terminates unnaturally, ifCurtailed: > should do it. > > > > At 04:26 PM 10/12/2006, Joerg Beekmann wrote: > >> What is the best way to arrange for a notification when a given > >> terminates, naturally or otherwise? I've tried the following but it > >> never results in anything: > >> > >> block := [10 timesRepeat: [(Delay forMilliseconds: 100) wait. > Transcript > >> show: '.']]. > >> [block forkAt: 10] > >> on: Process terminateSignal > >> do: [:ex| Transcript show: 'done.']. > >> > >> In fact I can't figure out that the terminateSignal is good for > it > >> is always caught when a process is created on a block: > >> > >> forBlock: aBlock priority: anInteger > >> | newProcess | > >> newProcess := self new. > >> newProcess suspendedContext: > >> [aBlock > >> on: Process terminateSignal > >> do: [:ex | ex return]. > >> Processor activeProcess primTerminate] newContext. > >> newProcess priority: anInteger. > >> ^newProcess > >> > >> ----- > >> Joerg Beekmann > >> DeepCove Labs > >> 4th floor 595 Howe Street > >> Vancouver, BC, V6C 2T5 > >> voice +1.604.689.0322 > >> fax +1.604.689.0311 > >> [hidden email] > >> > >> > >> CONFIDENTIALITY NOTICE > >> Unless otherwise indicated this email contains information that is > >> private > >> and confidential. If you have received it in error, please notify > >> sender > >> and delete this message along with any attachments. > > > > -- > > Alan Knight [|], Cincom Smalltalk Development > > [hidden email] > > [hidden email] > > http://www.cincom.com/smalltalk > > > > "The Static Typing Philosophy: Make it fast. Make it right. Make it > run." - Niall Ross > > > > |
Start another process that will periodically poll #isTerminated on the
original process, maybe ? Joerg Beekmann wrote: > The schemes suggested will work when I'm creating the process, as I was > in my example. But in my case I don't have control over the creation of > the process. > > So restating the question: given an arbitrary process, can I arrange to > be informed when the process ends? > > Joerg > > > > ----- > Joerg Beekmann > DeepCove Labs > 4th floor 595 Howe Street > Vancouver, BC, V6C 2T5 > voice +1.604.689.0322 > fax +1.604.689.0311 > [hidden email] > > > CONFIDENTIALITY NOTICE > Unless otherwise indicated this email contains information that is > private > and confidential. If you have received it in error, please notify the > sender > and delete this message along with any attachments. > > >>-----Original Message----- >>From: Dave Stevenson [mailto:[hidden email]] >>Sent: October 12, 2006 2:17 PM >>To: Alan Knight >>Cc: Joerg Beekmann; vwnc-list >>Subject: Re: How to be informed when a process terminates >> >>That doesn't cover natural termination: >> >> [[(Delay forSeconds: 2) wait. >> Transcript show: 'work done'] >> forkAt: 10] >> ensure: [Transcript show: 'forked']. >> >>Try using a semaphore: >> >> | sem | >> sem := Semaphore new. >> >> [sem wait. >> Transcript show: 'work done'] forkAt: 10. >> >> [[(Delay forSeconds: 2) wait] ensure: [sem signal]] >> forkAt: 10. >> >> Transcript show: 'forked'. >> >>Dave >> >>Alan Knight wrote: >> >>>If you control the spawning of the process, just do >>> [block forkAt: 10] ensure: [Transcript show: 'done']. >>> >>>If you only want to know if it terminates unnaturally, ifCurtailed: >> >>should do it. >> >>>At 04:26 PM 10/12/2006, Joerg Beekmann wrote: >>> >>>>What is the best way to arrange for a notification when a given > > process > >>>>terminates, naturally or otherwise? I've tried the following but it >>>>never results in anything: >>>> >>>>block := [10 timesRepeat: [(Delay forMilliseconds: 100) wait. >> >>Transcript >> >>>>show: '.']]. >>>>[block forkAt: 10] >>>> on: Process terminateSignal >>>> do: [:ex| Transcript show: 'done.']. >>>> >>>>In fact I can't figure out that the terminateSignal is good for > > since > >>it >> >>>>is always caught when a process is created on a block: >>>> >>>>forBlock: aBlock priority: anInteger >>>> | newProcess | >>>> newProcess := self new. >>>> newProcess suspendedContext: >>>> [aBlock >>>> on: Process terminateSignal >>>> do: [:ex | ex return]. >>>> Processor activeProcess primTerminate] newContext. >>>> newProcess priority: anInteger. >>>> ^newProcess >>>> >>>>----- >>>>Joerg Beekmann >>>>DeepCove Labs >>>>4th floor 595 Howe Street >>>>Vancouver, BC, V6C 2T5 >>>>voice +1.604.689.0322 >>>>fax +1.604.689.0311 >>>>[hidden email] >>>> >>>> >>>>CONFIDENTIALITY NOTICE >>>>Unless otherwise indicated this email contains information that is >>>>private >>>>and confidential. If you have received it in error, please notify > > the > >>>>sender >>>>and delete this message along with any attachments. >>> >>>-- >>>Alan Knight [|], Cincom Smalltalk Development >>>[hidden email] >>>[hidden email] >>>http://www.cincom.com/smalltalk >>> >>>"The Static Typing Philosophy: Make it fast. Make it right. Make it >> >>run." - Niall Ross >> >>> > > |
In reply to this post by kobetic
Martin Kobetic wrote:
> > The terminate signal is used to terminate process while it's executing, > not when it finishes normally. Modeling it as an exception allows to > reuse exception unwinding for proper behavior of #ensure: blocks in the > face of process termination. But, as we know, #ensure: blocks are not always executed correctly in the face of process termination. This was discussed early this year on this list, in these threads: * [Annoying] Single-process deadlock in VW7.4 -- hole in #ensure: w.r.t. #terminate * Debugger/Highlighter Freezes Image * Unwind blocks and terminate [was: Re: Debugger/Highlighter Freezes Image] I remember seeing a message (that I can't find right now) that this bug was scheduled to be fixed in VW 7.5. Is this still true? Does anyone have the AR number for this? Regards, -Martin |
In reply to this post by kobetic
Ok so we need to be creative. That's the conclusion we've come to.
I was hoping I had missed some simple mechanism like registering an interest in a process state change event. Joerg ----- Joerg Beekmann DeepCove Labs 4th floor 595 Howe Street Vancouver, BC, V6C 2T5 voice +1.604.689.0322 fax +1.604.689.0311 [hidden email] CONFIDENTIALITY NOTICE Unless otherwise indicated this email contains information that is private and confidential. If you have received it in error, please notify the sender and delete this message along with any attachments. > -----Original Message----- > From: Martin Kobetic [mailto:[hidden email]] > Sent: October 12, 2006 2:56 PM > To: Joerg Beekmann > Cc: vwnc-list > Subject: Re: How to be informed when a process terminates > > Start another process that will periodically poll #isTerminated on the > original process, maybe ? > > Joerg Beekmann wrote: > > > The schemes suggested will work when I'm creating the process, as I > > in my example. But in my case I don't have control over the creation of > > the process. > > > > So restating the question: given an arbitrary process, can I arrange to > > be informed when the process ends? > > > > Joerg > > > > > > > > ----- > > Joerg Beekmann > > DeepCove Labs > > 4th floor 595 Howe Street > > Vancouver, BC, V6C 2T5 > > voice +1.604.689.0322 > > fax +1.604.689.0311 > > [hidden email] > > > > > > CONFIDENTIALITY NOTICE > > Unless otherwise indicated this email contains information that is > > private > > and confidential. If you have received it in error, please notify > > sender > > and delete this message along with any attachments. > > > > > >>-----Original Message----- > >>From: Dave Stevenson [mailto:[hidden email]] > >>Sent: October 12, 2006 2:17 PM > >>To: Alan Knight > >>Cc: Joerg Beekmann; vwnc-list > >>Subject: Re: How to be informed when a process terminates > >> > >>That doesn't cover natural termination: > >> > >> [[(Delay forSeconds: 2) wait. > >> Transcript show: 'work done'] > >> forkAt: 10] > >> ensure: [Transcript show: 'forked']. > >> > >>Try using a semaphore: > >> > >> | sem | > >> sem := Semaphore new. > >> > >> [sem wait. > >> Transcript show: 'work done'] forkAt: 10. > >> > >> [[(Delay forSeconds: 2) wait] ensure: [sem signal]] > >> forkAt: 10. > >> > >> Transcript show: 'forked'. > >> > >>Dave > >> > >>Alan Knight wrote: > >> > >>>If you control the spawning of the process, just do > >>> [block forkAt: 10] ensure: [Transcript show: 'done']. > >>> > >>>If you only want to know if it terminates unnaturally, ifCurtailed: > >> > >>should do it. > >> > >>>At 04:26 PM 10/12/2006, Joerg Beekmann wrote: > >>> > >>>>What is the best way to arrange for a notification when a given > > > > process > > > >>>>terminates, naturally or otherwise? I've tried the following but > >>>>never results in anything: > >>>> > >>>>block := [10 timesRepeat: [(Delay forMilliseconds: 100) wait. > >> > >>Transcript > >> > >>>>show: '.']]. > >>>>[block forkAt: 10] > >>>> on: Process terminateSignal > >>>> do: [:ex| Transcript show: 'done.']. > >>>> > >>>>In fact I can't figure out that the terminateSignal is good for > > > > since > > > >>it > >> > >>>>is always caught when a process is created on a block: > >>>> > >>>>forBlock: aBlock priority: anInteger > >>>> | newProcess | > >>>> newProcess := self new. > >>>> newProcess suspendedContext: > >>>> [aBlock > >>>> on: Process terminateSignal > >>>> do: [:ex | ex return]. > >>>> Processor activeProcess primTerminate] newContext. > >>>> newProcess priority: anInteger. > >>>> ^newProcess > >>>> > >>>>----- > >>>>Joerg Beekmann > >>>>DeepCove Labs > >>>>4th floor 595 Howe Street > >>>>Vancouver, BC, V6C 2T5 > >>>>voice +1.604.689.0322 > >>>>fax +1.604.689.0311 > >>>>[hidden email] > >>>> > >>>> > >>>>CONFIDENTIALITY NOTICE > >>>>Unless otherwise indicated this email contains information that is > >>>>private > >>>>and confidential. If you have received it in error, please notify > > > > the > > > >>>>sender > >>>>and delete this message along with any attachments. > >>> > >>>-- > >>>Alan Knight [|], Cincom Smalltalk Development > >>>[hidden email] > >>>[hidden email] > >>>http://www.cincom.com/smalltalk > >>> > >>>"The Static Typing Philosophy: Make it fast. Make it right. Make it > >> > >>run." - Niall Ross > >> > >>> > > > > |
In reply to this post by Martin McClure
Umm, what?!
Cheers, -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. -----Original Message----- From: Martin McClure [mailto:[hidden email]] Sent: Thursday, October 12, 2006 3:09 PM To: Martin Kobetic Cc: vwnc-list Subject: Terminate and #ensure: blocks [was: Re: How to be informed when a process terminates] Martin Kobetic wrote: > > The terminate signal is used to terminate process while it's executing, > not when it finishes normally. Modeling it as an exception allows to > reuse exception unwinding for proper behavior of #ensure: blocks in the > face of process termination. But, as we know, #ensure: blocks are not always executed correctly in the face of process termination. This was discussed early this year on this list, in these threads: * [Annoying] Single-process deadlock in VW7.4 -- hole in #ensure: w.r.t. #terminate * Debugger/Highlighter Freezes Image * Unwind blocks and terminate [was: Re: Debugger/Highlighter Freezes Image] I remember seeing a message (that I can't find right now) that this bug was scheduled to be fixed in VW 7.5. Is this still true? Does anyone have the AR number for this? Regards, -Martin |
In reply to this post by Martin McClure
Martin
Thank you for this tidbit, it may explain a few things. Now knowing if it actually does explain things is another question. > > But, as we know, #ensure: blocks are not always executed correctly in > the face of process termination. This was discussed early this year on > this list, in these threads: > * [Annoying] Single-process deadlock in VW7.4 -- hole in #ensure: w.r.t. > #terminate > * Debugger/Highlighter Freezes Image > * Unwind blocks and terminate [was: Re: Debugger/Highlighter Freezes > Image] > > > I remember seeing a message (that I can't find right now) that this bug > was scheduled to be fixed in VW 7.5. Is this still true? Does anyone > have the AR number for this? > |
In reply to this post by Martin McClure
Yes, we know :(. The AR is 50200: "Process termination at the wrong time
can cause unwind code not to run" and is unfortunately still open largely because we still didn't come to an agreement on the issue internally. It is marked critical so it was definitely meant to be resolved in 7.5, but with the deadlines coming fast I don't know. Moreover this is the sort of thing that should go in early in the release cycle to have enough time to shake out the issues it might cause. I'm afraid I don't have anything more upbeat on this atm. Martin Martin McClure wrote: > Martin Kobetic wrote: > >> >> The terminate signal is used to terminate process while it's >> executing, not when it finishes normally. Modeling it as an exception >> allows to reuse exception unwinding for proper behavior of #ensure: >> blocks in the face of process termination. > > > But, as we know, #ensure: blocks are not always executed correctly in > the face of process termination. This was discussed early this year on > this list, in these threads: > * [Annoying] Single-process deadlock in VW7.4 -- hole in #ensure: w.r.t. > #terminate > * Debugger/Highlighter Freezes Image > * Unwind blocks and terminate [was: Re: Debugger/Highlighter Freezes > Image] > > > I remember seeing a message (that I can't find right now) that this bug > was scheduled to be fixed in VW 7.5. Is this still true? Does anyone > have the AR number for this? > > Regards, > > -Martin > |
Martin Kobetic wrote:
> Yes, we know :(. The AR is 50200: "Process termination at the wrong time > can cause unwind code not to run" and is unfortunately still open > largely because we still didn't come to an agreement on the issue > internally. It is marked critical so it was definitely meant to be > resolved in 7.5, but with the deadlines coming fast I don't know. > Moreover this is the sort of thing that should go in early in the > release cycle to have enough time to shake out the issues it might > cause. I'm afraid I don't have anything more upbeat on this atm. > Thanks for the update. This issue is still causing us grief, so we're interested in a fix. I did have some ideas about how to fix it when I dug into it in depth in January, so I'd be happy to discuss the options with the interested parties within Cincom if it would help. -Martin |
In reply to this post by Martin McClure
Martin McClure <[hidden email]> wrote:
| Martin Kobetic wrote: | > Yes, we know :(. The AR is 50200: "Process termination at the wrong time | > can cause unwind code not to run" and is unfortunately still open | > largely because we still didn't come to an agreement on the issue | > internally. It is marked critical so it was definitely meant to be | > resolved in 7.5, but with the deadlines coming fast I don't know. | > Moreover this is the sort of thing that should go in early in the | > release cycle to have enough time to shake out the issues it might | > cause. I'm afraid I don't have anything more upbeat on this atm. | > | Thanks for the update. | This issue is still causing us grief, so we're interested in a fix. I | did have some ideas about how to fix it when I dug into it in depth in | January, so I'd be happy to discuss the options with the interested | parties within Cincom if it would help. Feel free. I;d be happier if the discussion were hed on vw-dev though. --- Eliot Miranda ,,,^..^,,, mailto:[hidden email] VisualWorks Engineering, Cincom Smalltalk: scene not herd Tel +1 408 216 4581 3350 Scott Blvd, Bldg 36 Suite B, Santa Clara, CA 95054 USA Fax +1 408 216 4500 |
[hidden email] wrote:
> | This issue is still causing us grief, so we're interested in a fix. I > | did have some ideas about how to fix it when I dug into it in depth in > | January, so I'd be happy to discuss the options with the interested > | parties within Cincom if it would help. > > Feel free. I;d be happier if the discussion were hed on vw-dev though. Okay, once I manage to shove our current release out the door, I'll refresh my memory and start a discussion there. Regards, -Martin |
In reply to this post by Joerg Beekmann, DeepCove Labs (YVR)
Joerg
You could always change the send stack and insert a context that notifies you that the process exited normally. Terry =========================================================== Terry Raymond Smalltalk Professional Debug Package Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== > -----Original Message----- > From: Joerg Beekmann [mailto:[hidden email]] > Sent: Thursday, October 12, 2006 5:31 PM > To: Dave Stevenson; Alan Knight > Cc: vwnc-list > Subject: RE: How to be informed when a process terminates > > The schemes suggested will work when I'm creating the process, as I was > in my example. But in my case I don't have control over the creation of > the process. > > So restating the question: given an arbitrary process, can I arrange to > be informed when the process ends? > > Joerg > > > > ----- > Joerg Beekmann > DeepCove Labs > 4th floor 595 Howe Street > Vancouver, BC, V6C 2T5 > voice +1.604.689.0322 > fax +1.604.689.0311 > [hidden email] > > > CONFIDENTIALITY NOTICE > Unless otherwise indicated this email contains information that is > private > and confidential. If you have received it in error, please notify the > sender > and delete this message along with any attachments. > > > -----Original Message----- > > From: Dave Stevenson [mailto:[hidden email]] > > Sent: October 12, 2006 2:17 PM > > To: Alan Knight > > Cc: Joerg Beekmann; vwnc-list > > Subject: Re: How to be informed when a process terminates > > > > That doesn't cover natural termination: > > > > [[(Delay forSeconds: 2) wait. > > Transcript show: 'work done'] > > forkAt: 10] > > ensure: [Transcript show: 'forked']. > > > > Try using a semaphore: > > > > | sem | > > sem := Semaphore new. > > > > [sem wait. > > Transcript show: 'work done'] forkAt: 10. > > > > [[(Delay forSeconds: 2) wait] ensure: [sem signal]] > > forkAt: 10. > > > > Transcript show: 'forked'. > > > > Dave > > > > Alan Knight wrote: > > > If you control the spawning of the process, just do > > > [block forkAt: 10] ensure: [Transcript show: 'done']. > > > > > > If you only want to know if it terminates unnaturally, ifCurtailed: > > should do it. > > > > > > At 04:26 PM 10/12/2006, Joerg Beekmann wrote: > > >> What is the best way to arrange for a notification when a given > process > > >> terminates, naturally or otherwise? I've tried the following but it > > >> never results in anything: > > >> > > >> block := [10 timesRepeat: [(Delay forMilliseconds: 100) wait. > > Transcript > > >> show: '.']]. > > >> [block forkAt: 10] > > >> on: Process terminateSignal > > >> do: [:ex| Transcript show: 'done.']. > > >> > > >> In fact I can't figure out that the terminateSignal is good for > since > > it > > >> is always caught when a process is created on a block: > > >> > > >> forBlock: aBlock priority: anInteger > > >> | newProcess | > > >> newProcess := self new. > > >> newProcess suspendedContext: > > >> [aBlock > > >> on: Process terminateSignal > > >> do: [:ex | ex return]. > > >> Processor activeProcess primTerminate] newContext. > > >> newProcess priority: anInteger. > > >> ^newProcess > > >> > > >> ----- > > >> Joerg Beekmann > > >> DeepCove Labs > > >> 4th floor 595 Howe Street > > >> Vancouver, BC, V6C 2T5 > > >> voice +1.604.689.0322 > > >> fax +1.604.689.0311 > > >> [hidden email] > > >> > > >> > > >> CONFIDENTIALITY NOTICE > > >> Unless otherwise indicated this email contains information that is > > >> private > > >> and confidential. If you have received it in error, please notify > the > > >> sender > > >> and delete this message along with any attachments. > > > > > > -- > > > Alan Knight [|], Cincom Smalltalk Development > > > [hidden email] > > > [hidden email] > > > http://www.cincom.com/smalltalk > > > > > > "The Static Typing Philosophy: Make it fast. Make it right. Make it > > run." - Niall Ross > > > > > > |
In reply to this post by eliot-2
All,
In the ObjectStudio 8 project we have developed a solution for a similar task: In ObjectStudio 8 you can attach semaphore to a process which will be signalled when the process terminates. AR 50827 describes the setup to hook into class Process and introduces a new method called finalTerminate which calls primTerminate by default and is used in ObjectStudio 8 to be overridden by triggering any termination semaphore: finalTerminate (self environment at: #terminationSemaphores ifAbsent: [OrderedCollection new]) do: [:each | each signal]. ^self primTerminate Maybe we can use this discussion to generalize the ObjectStudio 8 solution and to have it included directly in the base. I still hope that AR 50827 will make it soon. Georg PS: This is the ObjectStudio 8 way to set up the semaphore (Method from class Process: waitForThreadExitMilliseconds: aNumber | sem coll result | sem := Semaphore new. coll := self environment at: #terminationSemaphores ifAbsent: [self environment at: #terminationSemaphores put: OrderedCollection new]. coll add: sem. self isTerminated ifTrue: [^#Exit]. result := (sem waitFor: aNumber) ifTrue: [#Exit] ifFalse: [#Timeout]. coll remove: sem. ^result ":Section Reference waitForThreadExitMilliseconds: aNumber Description: Wait for the completion of this thread but no more than specified number of milliseconds. nil means indefinite wait. Assumptions: None. Return Value: A symbol. #Error -- error has occurred #Exit -- thread has terminated #Timeout -- wait has timed out Receiver Modified: No. :End" -----Ursprüngliche Nachricht----- Von: [hidden email] [mailto:[hidden email]] Gesendet: Freitag, 13. Oktober 2006 01:43 An: [hidden email] Cc: [hidden email]; [hidden email] Betreff: Re: Terminate and #ensure: blocks [was: Re: How to be informed when a process terminates] [...] |
On Oct 13, 2006, at 0:58, Georg Heeg wrote:
If you use a Semaphore... doesn't that mean that you can have one and only one thing waiting on completion? Or do you signal it until it's empty? -- Travis Griggs Objologist "I choose. Therefore, I Am" |
Travis, What we implemented in
the ObjectStudio 8 project is ObjectStudio 7 compatibility. Multiple semaphores
can wait on the same process termination, they all get signalled. The use case of sharing
the wait semaphore by more processes is in my humble opinion a more general semaphore
issue. Georg Von: Travis Griggs
[mailto:[hidden email]] On Oct 13, 2006, at 0:58, Georg Heeg wrote:
All, In the ObjectStudio 8 project we have developed a solution for a
similar task: In ObjectStudio 8 you can attach semaphore to a process which
will be signalled when the process terminates. AR 50827 describes the setup to hook into class Process and introduces
a new method called finalTerminate which calls primTerminate by default and
is used in ObjectStudio 8 to be overridden by triggering any termination semaphore: finalTerminate (self
environment at: #terminationSemaphores ifAbsent:
[OrderedCollection new]) do: [:each | each signal]. ^self
primTerminate Maybe we can use this discussion to generalize the ObjectStudio 8
solution and to have it included directly in the base. I still hope that AR
50827 will make it soon. If you use a Semaphore... doesn't that mean that you can have one and
only one thing waiting on completion? Or do you signal it until it's empty? -- Travis Griggs Objologist "I choose.
Therefore, I Am"
|
Free forum by Nabble | Edit this page |