[Pharo-project] Analog to Dolphin's #forkMainIfMain?
Is there anything in Pharo that starts a new main thread to carry on for one that is about to get blocked? It might be that Pharo does not need it, since sockets are serviced by the VM, where Dolphin (at least prior to overlapped calls) did the I/O through the event loop; if the main thread stopped, so did Windows event dispatching, and hence no socket I/O. Dolphin to some extent, and WindowBuilder to (IIRC) a large extent create modal loops in Smalltalk code. I see a few references to such things in Pharo, but I'm fairly lost. Where should I start reading and/or browsing? Bill
2009/8/15 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Is there anything in Pharo that starts a new main thread to carry on for one that is about to get blocked? Â It might be that Pharo does not need it, since sockets are serviced by the VM, where Dolphin (at least prior to overlapped calls) did the I/O through the event loop; if the main thread stopped, so did Windows event dispatching, and hence no socket I/O.
There is such thing. Try to explore the way how debugger handling this (when process you want to debug is current UI process), or when you pressing interrupt key. See Debugger>>openOn: process context: context label: title contents: contentsStringOrNil fullView: bool at 'Project spawnNewProcessIfThisIsUI: process'
Dolphin to some extent, and WindowBuilder to (IIRC) a large extent create modal loops in Smalltalk code. Â I see a few references to such things in Pharo, but I'm fairly lost. Â Where should I start reading and/or browsing?
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
THANKS!!! -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Saturday, August 15, 2009 3:29 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain? 2009/8/15 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Is there anything in Pharo that starts a new main thread to carry on for one that is about to get blocked? Â It might be that Pharo does not need it, since sockets are serviced by the VM, where Dolphin (at least prior to overlapped calls) did the I/O through the event loop; if the main thread stopped, so did Windows event dispatching, and hence no socket I/O.
There is such thing. Try to explore the way how debugger handling this (when process you want to debug is current UI process), or when you pressing interrupt key. See Debugger>>openOn: process context: context label: title contents: contentsStringOrNil fullView: bool at 'Project spawnNewProcessIfThisIsUI: process'
Dolphin to some extent, and WindowBuilder to (IIRC) a large extent create modal loops in Smalltalk code. Â I see a few references to such things in Pharo, but I'm fairly lost. Â Where should I start reading and/or browsing?
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Sig, all, I have been preparing MC packages with classes and method designed to soften the blow of moving much of my domain code to Pharo. In this case, I have some sends of ProcessorSchedler>>forkMainIfMain, so I created that method. Initially, I made it emtpy, and then based on what you helpe me find, I tried ProcessorScheduler>>forkMainIfMain Project spawnProcessIfThisIsUI:self activeProcess. The above gets called from something that then immediately waits on a semaphore that is signalled by one of two threads. One of the threads waits on a timer, the other tries to evaluate a block; creating a background worker thread that will run for a limited time. There is a test case that tries various combinations, some of which should succeed and some should time out. I have used these things in production in Dolphin for some time. In Dolphin, #forkMainIfMain allows the UI to be responsive during these tests, but trying the above in Pharo turns ugly. There are problems that appear to related to two UI processes - running short of events or something like that. The tests run for only a few seconds, though I suppose I could try to allow enough time to look around, but then I'm probably not the right person to do the looking anyway. DUMB question: the argument to #spawnProcessIfThisIsUI: is named suspendedProcess. Do I need to ensure the process in question is indeed suspended before entering the method? If so, then I start wondering how to get there from #forkMainIfMain, but it's a little late for my brain to take on that question. One thing is certain: what I tried did not work. There were errors from the event loop and even some screen scarring. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Saturday, August 15, 2009 3:29 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain? 2009/8/15 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Is there anything in Pharo that starts a new main thread to carry on for one that is about to get blocked? Â It might be that Pharo does not need it, since sockets are serviced by the VM, where Dolphin (at least prior to overlapped calls) did the I/O through the event loop; if the main thread stopped, so did Windows event dispatching, and hence no socket I/O.
There is such thing. Try to explore the way how debugger handling this (when process you want to debug is current UI process), or when you pressing interrupt key. See Debugger>>openOn: process context: context label: title contents: contentsStringOrNil fullView: bool at 'Project spawnNewProcessIfThisIsUI: process'
Dolphin to some extent, and WindowBuilder to (IIRC) a large extent create modal loops in Smalltalk code. Â I see a few references to such things in Pharo, but I'm fairly lost. Â Where should I start reading and/or browsing?
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Bill (and igor) I would love to continue to remove Project from the image so the "spawnProcessIfThisIsUI:self activeProcess." should probably find another host. Do you have an idea about the class that could be the natural place to define such a method? if so can you propose a change? Stef On Aug 16, 2009, at 5:57 AM, Schwab,Wilhelm K wrote:
Sig, all,
I have been preparing MC packages with classes and method designed to soften the blow of moving much of my domain code to Pharo. In this case, I have some sends of ProcessorSchedler>>forkMainIfMain, so I created that method. Initially, I made it emtpy, and then based on what you helpe me find, I tried
ProcessorScheduler>>forkMainIfMain Project spawnProcessIfThisIsUI:self activeProcess.
The above gets called from something that then immediately waits on a semaphore that is signalled by one of two threads. One of the threads waits on a timer, the other tries to evaluate a block; creating a background worker thread that will run for a limited time. There is a test case that tries various combinations, some of which should succeed and some should time out. I have used these things in production in Dolphin for some time.
In Dolphin, #forkMainIfMain allows the UI to be responsive during these tests, but trying the above in Pharo turns ugly. There are problems that appear to related to two UI processes - running short of events or something like that. The tests run for only a few seconds, though I suppose I could try to allow enough time to look around, but then I'm probably not the right person to do the looking anyway.
DUMB question: the argument to #spawnProcessIfThisIsUI: is named suspendedProcess. Do I need to ensure the process in question is indeed suspended before entering the method? If so, then I start wondering how to get there from #forkMainIfMain, but it's a little late for my brain to take on that question.
One thing is certain: what I tried did not work. There were errors from the event loop and even some screen scarring.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Igor Stasenko Sent: Saturday, August 15, 2009 3:29 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain?
2009/8/15 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Is there anything in Pharo that starts a new main thread to carry on for one that is about to get blocked? It might be that Pharo does not need it, since sockets are serviced by the VM, where Dolphin (at least prior to overlapped calls) did the I/O through the event loop; if the main thread stopped, so did Windows event dispatching, and hence no socket I/O.
There is such thing. Try to explore the way how debugger handling this (when process you want to debug is current UI process), or when you pressing interrupt key.
See Debugger>>openOn: process context: context label: title contents: contentsStringOrNil fullView: bool
at 'Project spawnNewProcessIfThisIsUI: process'
Dolphin to some extent, and WindowBuilder to (IIRC) a large extent create modal loops in Smalltalk code. I see a few references to such things in Pharo, but I'm fairly lost. Where should I start reading and/or browsing?
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/8/16 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Bill (and igor)
I would love to continue to remove Project from the image so the "spawnProcessIfThisIsUI:self activeProcess." should probably find another host. Do you have an idea about the class that could be the natural place to define such a method? if so can you propose a change?
IMO WorldState is the way to go. Since you removing Project, then you couldn't have multiple worlds, right?
Stef
On Aug 16, 2009, at 5:57 AM, Schwab,Wilhelm K wrote:
Sig, all,
I have been preparing MC packages with classes and method designed to soften the blow of moving much of my domain code to Pharo. Â In this case, I have some sends of ProcessorSchedler>>forkMainIfMain, so I created that method. Â Initially, I made it emtpy, and then based on what you helpe me find, I tried
ProcessorScheduler>>forkMainIfMain  Project spawnProcessIfThisIsUI:self activeProcess.
The above gets called from something that then immediately waits on a semaphore that is signalled by one of two threads. Â One of the threads waits on a timer, the other tries to evaluate a block; creating a background worker thread that will run for a limited time. Â There is a test case that tries various combinations, some of which should succeed and some should time out. Â I have used these things in production in Dolphin for some time.
In Dolphin, #forkMainIfMain allows the UI to be responsive during these tests, but trying the above in Pharo turns ugly. Â There are problems that appear to related to two UI processes - running short of events or something like that. Â The tests run for only a few seconds, though I suppose I could try to allow enough time to look around, but then I'm probably not the right person to do the looking anyway.
DUMB question: the argument to #spawnProcessIfThisIsUI: is named suspendedProcess. Â Do I need to ensure the process in question is indeed suspended before entering the method? Â If so, then I start wondering how to get there from #forkMainIfMain, but it's a little late for my brain to take on that question.
One thing is certain: what I tried did not work. Â There were errors from the event loop and even some screen scarring.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Igor Stasenko Sent: Saturday, August 15, 2009 3:29 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain?
2009/8/15 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Is there anything in Pharo that starts a new main thread to carry on for one that is about to get blocked? Â It might be that Pharo does not need it, since sockets are serviced by the VM, where Dolphin (at least prior to overlapped calls) did the I/O through the event loop; if the main thread stopped, so did Windows event dispatching, and hence no socket I/O.
There is such thing. Try to explore the way how debugger handling this (when process you want to debug is current UI process), or when you pressing interrupt key.
See Debugger>>openOn: process context: context label: title contents: contentsStringOrNil fullView: bool
at 'Project spawnNewProcessIfThisIsUI: process'
Dolphin to some extent, and WindowBuilder to (IIRC) a large extent create modal loops in Smalltalk code. Â I see a few references to such things in Pharo, but I'm fairly lost. Â Where should I start reading and/or browsing?
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Aug 16, 2009, at 12:07 PM, Igor Stasenko wrote:
2009/8/16 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Bill (and igor)
I would love to continue to remove Project from the image so the "spawnProcessIfThisIsUI:self activeProcess." should probably find another host. Do you have an idea about the class that could be the natural place to define such a method? if so can you propose a change?
IMO WorldState is the way to go. Since you removing Project, then you couldn't have multiple worlds, right? yes projects are totally broken in pharo.
Stef
On Aug 16, 2009, at 5:57 AM, Schwab,Wilhelm K wrote:
Sig, all,
I have been preparing MC packages with classes and method designed to soften the blow of moving much of my domain code to Pharo. In this case, I have some sends of ProcessorSchedler>>forkMainIfMain, so I created that method. Initially, I made it emtpy, and then based on what you helpe me find, I tried
ProcessorScheduler>>forkMainIfMain Project spawnProcessIfThisIsUI:self activeProcess.
The above gets called from something that then immediately waits on a semaphore that is signalled by one of two threads. One of the threads waits on a timer, the other tries to evaluate a block; creating a background worker thread that will run for a limited time. There is a test case that tries various combinations, some of which should succeed and some should time out. I have used these things in production in Dolphin for some time.
In Dolphin, #forkMainIfMain allows the UI to be responsive during these tests, but trying the above in Pharo turns ugly. There are problems that appear to related to two UI processes - running short of events or something like that. The tests run for only a few seconds, though I suppose I could try to allow enough time to look around, but then I'm probably not the right person to do the looking anyway.
DUMB question: the argument to #spawnProcessIfThisIsUI: is named suspendedProcess. Do I need to ensure the process in question is indeed suspended before entering the method? If so, then I start wondering how to get there from #forkMainIfMain, but it's a little late for my brain to take on that question.
One thing is certain: what I tried did not work. There were errors from the event loop and even some screen scarring.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Igor Stasenko Sent: Saturday, August 15, 2009 3:29 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain?
2009/8/15 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Is there anything in Pharo that starts a new main thread to carry on for one that is about to get blocked? It might be that Pharo does not need it, since sockets are serviced by the VM, where Dolphin (at least prior to overlapped calls) did the I/O through the event loop; if the main thread stopped, so did Windows event dispatching, and hence no socket I/O.
There is such thing. Try to explore the way how debugger handling this (when process you want to debug is current UI process), or when you pressing interrupt key.
See Debugger>>openOn: process context: context label: title contents: contentsStringOrNil fullView: bool
at 'Project spawnNewProcessIfThisIsUI: process'
Dolphin to some extent, and WindowBuilder to (IIRC) a large extent create modal loops in Smalltalk code. I see a few references to such things in Pharo, but I'm fairly lost. Where should I start reading and/or browsing?
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stef, When I saw Project was involved, I immediately though you and the other usual suspects in the "cleaning" business - you guys do great work, and it can't be easy. FWIW, Dolphin defines ProcessorScheduler>>forkMainIfMain, and I have code that uses same, so there likely will be such a method in my image at least. Of course, I can write it in terms of anything else you might want to use, but it seems a logical choice to me. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Sunday, August 16, 2009 4:18 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain? Bill (and igor) I would love to continue to remove Project from the image so the "spawnProcessIfThisIsUI:self activeProcess." should probably find another host. Do you have an idea about the class that could be the natural place to define such a method? if so can you propose a change? Stef On Aug 16, 2009, at 5:57 AM, Schwab,Wilhelm K wrote:
Sig, all,
I have been preparing MC packages with classes and method designed to soften the blow of moving much of my domain code to Pharo. In this case, I have some sends of ProcessorSchedler>>forkMainIfMain, so I created that method. Initially, I made it emtpy, and then based on what you helpe me find, I tried
ProcessorScheduler>>forkMainIfMain Project spawnProcessIfThisIsUI:self activeProcess.
The above gets called from something that then immediately waits on a semaphore that is signalled by one of two threads. One of the threads waits on a timer, the other tries to evaluate a block; creating a background worker thread that will run for a limited time. There is a test case that tries various combinations, some of which should succeed and some should time out. I have used these things in production in Dolphin for some time.
In Dolphin, #forkMainIfMain allows the UI to be responsive during these tests, but trying the above in Pharo turns ugly. There are problems that appear to related to two UI processes - running short of events or something like that. The tests run for only a few seconds, though I suppose I could try to allow enough time to look around, but then I'm probably not the right person to do the looking anyway.
DUMB question: the argument to #spawnProcessIfThisIsUI: is named suspendedProcess. Do I need to ensure the process in question is indeed suspended before entering the method? If so, then I start wondering how to get there from #forkMainIfMain, but it's a little late for my brain to take on that question.
One thing is certain: what I tried did not work. There were errors from the event loop and even some screen scarring.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Igor Stasenko Sent: Saturday, August 15, 2009 3:29 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain?
2009/8/15 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Is there anything in Pharo that starts a new main thread to carry on for one that is about to get blocked? It might be that Pharo does not need it, since sockets are serviced by the VM, where Dolphin (at least prior to overlapped calls) did the I/O through the event loop; if the main thread stopped, so did Windows event dispatching, and hence no socket I/O.
There is such thing. Try to explore the way how debugger handling this (when process you want to debug is current UI process), or when you pressing interrupt key.
See Debugger>>openOn: process context: context label: title contents: contentsStringOrNil fullView: bool
at 'Project spawnNewProcessIfThisIsUI: process'
Dolphin to some extent, and WindowBuilder to (IIRC) a large extent create modal loops in Smalltalk code. I see a few references to such things in Pharo, but I'm fairly lost. Where should I start reading and/or browsing?
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/8/16 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Sig, all,
I have been preparing MC packages with classes and method designed to soften the blow of moving much of my domain code to Pharo. Â In this case, I have some sends of ProcessorSchedler>>forkMainIfMain, so I created that method. Â Initially, I made it emtpy, and then based on what you helpe me find, I tried
ProcessorScheduler>>forkMainIfMain  Project spawnProcessIfThisIsUI:self activeProcess.
The above gets called from something that then immediately waits on a semaphore that is signalled by one of two threads. Â One of the threads waits on a timer, the other tries to evaluate a block; creating a background worker thread that will run for a limited time. Â There is a test case that tries various combinations, some of which should succeed and some should time out. Â I have used these things in production in Dolphin for some time.
In Dolphin, #forkMainIfMain allows the UI to be responsive during these tests, but trying the above in Pharo turns ugly. Â There are problems that appear to related to two UI processes - running short of events or something like that. Â The tests run for only a few seconds, though I suppose I could try to allow enough time to look around, but then I'm probably not the right person to do the looking anyway.
DUMB question: the argument to #spawnProcessIfThisIsUI: is named suspendedProcess. Â Do I need to ensure the process in question is indeed suspended before entering the method? Â If so, then I start wondering how to get there from #forkMainIfMain, but it's a little late for my brain to take on that question.
One thing is certain: what I tried did not work. Â There were errors from the event loop and even some screen scarring.
I think, once you spawn a new UI process by your code, you should prevent an old process from returning back to World/WorldState event handling, by simply terminating it after you done. Otherwise, again, take a look what debugger does, when you clicking 'proceed' on a process which being debugged and which was a UI process. It should do some tricks, otherwise you end up with two event loops polling the same event source.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Saturday, August 15, 2009 3:29 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain?
2009/8/15 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Is there anything in Pharo that starts a new main thread to carry on for one that is about to get blocked? Â It might be that Pharo does not need it, since sockets are serviced by the VM, where Dolphin (at least prior to overlapped calls) did the I/O through the event loop; if the main thread stopped, so did Windows event dispatching, and hence no socket I/O.
There is such thing. Try to explore the way how debugger handling this (when process you want to debug is current UI process), or when you pressing interrupt key.
See Debugger>>openOn: process context: context label: title contents: contentsStringOrNil fullView: bool
at 'Project spawnNewProcessIfThisIsUI: process'
Dolphin to some extent, and WindowBuilder to (IIRC) a large extent create modal loops in Smalltalk code. Â I see a few references to such things in Pharo, but I'm fairly lost. Â Where should I start reading and/or browsing?
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Sig, Two UI processes polling for input is probably what has happened. I should give some attention to how Dolphin prevents that. Two things that come to mind are raising the priority of a new UI thread to create a modal event loop, and (which Pharo almost certainly does too) starting a new UI thread when needed. My TimedEvaluator class has headless and "with progres" subclasses. The latter will need some porting, and perhaps the headless one should simply block, or at least do so in Pharo. Terminating the UI thread seems a little harsh, but that might be what is needed. Another option might be to suspend the old UI thread, start the new one, and then undo the damage at the end. Is that something that #forkMainIfMain should do automatically? One of the things that drives me nuts is whether a #suspend would stop the thread that is trying to do the work =:0 Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Sunday, August 16, 2009 5:05 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain? 2009/8/16 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Sig, all,
I have been preparing MC packages with classes and method designed to soften the blow of moving much of my domain code to Pharo. Â In this case, I have some sends of ProcessorSchedler>>forkMainIfMain, so I created that method. Â Initially, I made it emtpy, and then based on what you helpe me find, I tried
ProcessorScheduler>>forkMainIfMain  Project spawnProcessIfThisIsUI:self activeProcess.
The above gets called from something that then immediately waits on a semaphore that is signalled by one of two threads. Â One of the threads waits on a timer, the other tries to evaluate a block; creating a background worker thread that will run for a limited time. Â There is a test case that tries various combinations, some of which should succeed and some should time out. Â I have used these things in production in Dolphin for some time.
In Dolphin, #forkMainIfMain allows the UI to be responsive during these tests, but trying the above in Pharo turns ugly. Â There are problems that appear to related to two UI processes - running short of events or something like that. Â The tests run for only a few seconds, though I suppose I could try to allow enough time to look around, but then I'm probably not the right person to do the looking anyway.
DUMB question: the argument to #spawnProcessIfThisIsUI: is named suspendedProcess. Â Do I need to ensure the process in question is indeed suspended before entering the method? Â If so, then I start wondering how to get there from #forkMainIfMain, but it's a little late for my brain to take on that question.
One thing is certain: what I tried did not work. Â There were errors from the event loop and even some screen scarring.
I think, once you spawn a new UI process by your code, you should prevent an old process from returning back to World/WorldState event handling, by simply terminating it after you done. Otherwise, again, take a look what debugger does, when you clicking 'proceed' on a process which being debugged and which was a UI process. It should do some tricks, otherwise you end up with two event loops polling the same event source.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Saturday, August 15, 2009 3:29 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain?
2009/8/15 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Is there anything in Pharo that starts a new main thread to carry on for one that is about to get blocked? Â It might be that Pharo does not need it, since sockets are serviced by the VM, where Dolphin (at least prior to overlapped calls) did the I/O through the event loop; if the main thread stopped, so did Windows event dispatching, and hence no socket I/O.
There is such thing. Try to explore the way how debugger handling this (when process you want to debug is current UI process), or when you pressing interrupt key.
See Debugger>>openOn: process context: context label: title contents: contentsStringOrNil fullView: bool
at 'Project spawnNewProcessIfThisIsUI: process'
Dolphin to some extent, and WindowBuilder to (IIRC) a large extent create modal loops in Smalltalk code. Â I see a few references to such things in Pharo, but I'm fairly lost. Â Where should I start reading and/or browsing?
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/8/16 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Sig,
Two UI processes polling for input is probably what has happened. Â I should give some attention to how Dolphin prevents that. Â Two things that come to mind are raising the priority of a new UI thread to create a modal event loop, and (which Pharo almost certainly does too) starting a new UI thread when needed.
My TimedEvaluator class has headless and "with progres" subclasses. Â The latter will need some porting, and perhaps the headless one should simply block, or at least do so in Pharo.
Terminating the UI thread seems a little harsh, but that might be what is needed.
Sure it is what debugger does when you closing its window - it terminating the process you currently debugging. Nothing harsh or wrong and nothing to worry about (usually). :)
Another option might be to suspend the old UI thread, start the new one, and then undo the damage at the end.
There are is a little damage which is done when you doing that - mainly the event which is currently handled is lost, but since your intent to terminate the current process, as a result of event handling, nothing wrong with it. As for the rest , when you start a new UI process everything continues to work normally.
 Is that something that #forkMainIfMain should do automatically?  One of the things that drives me nuts is whether a #suspend would stop the thread that is trying to do the work =:0
There should be some process which polling the events from VM, even if they are not handled. The only case when its not needed at all is in headless mode. Otherwise , at least on windows, when VM internal event buffer overflows you start receiving warnings about it.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Sunday, August 16, 2009 5:05 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain?
2009/8/16 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Sig, all,
I have been preparing MC packages with classes and method designed to soften the blow of moving much of my domain code to Pharo. Â In this case, I have some sends of ProcessorSchedler>>forkMainIfMain, so I created that method. Â Initially, I made it emtpy, and then based on what you helpe me find, I tried
ProcessorScheduler>>forkMainIfMain  Project spawnProcessIfThisIsUI:self activeProcess.
The above gets called from something that then immediately waits on a semaphore that is signalled by one of two threads. Â One of the threads waits on a timer, the other tries to evaluate a block; creating a background worker thread that will run for a limited time. Â There is a test case that tries various combinations, some of which should succeed and some should time out. Â I have used these things in production in Dolphin for some time.
In Dolphin, #forkMainIfMain allows the UI to be responsive during these tests, but trying the above in Pharo turns ugly. Â There are problems that appear to related to two UI processes - running short of events or something like that. Â The tests run for only a few seconds, though I suppose I could try to allow enough time to look around, but then I'm probably not the right person to do the looking anyway.
DUMB question: the argument to #spawnProcessIfThisIsUI: is named suspendedProcess. Â Do I need to ensure the process in question is indeed suspended before entering the method? Â If so, then I start wondering how to get there from #forkMainIfMain, but it's a little late for my brain to take on that question.
One thing is certain: what I tried did not work. Â There were errors from the event loop and even some screen scarring.
I think, once you spawn a new UI process by your code, you should prevent an old process from returning back to World/WorldState event handling, by simply terminating it after you done. Otherwise, again, take a look what debugger does, when you clicking 'proceed' on a process which being debugged and which was a UI process. It should do some tricks, otherwise you end up with two event loops polling the same event source.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Saturday, August 15, 2009 3:29 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain?
2009/8/15 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Is there anything in Pharo that starts a new main thread to carry on for one that is about to get blocked? Â It might be that Pharo does not need it, since sockets are serviced by the VM, where Dolphin (at least prior to overlapped calls) did the I/O through the event loop; if the main thread stopped, so did Windows event dispatching, and hence no socket I/O.
There is such thing. Try to explore the way how debugger handling this (when process you want to debug is current UI process), or when you pressing interrupt key.
See Debugger>>openOn: process context: context label: title contents: contentsStringOrNil fullView: bool
at 'Project spawnNewProcessIfThisIsUI: process'
Dolphin to some extent, and WindowBuilder to (IIRC) a large extent create modal loops in Smalltalk code. Â I see a few references to such things in Pharo, but I'm fairly lost. Â Where should I start reading and/or browsing?
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Aug 16, 2009, at 4:57 17PM, Igor Stasenko wrote:
2009/8/16 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Sig,
Two UI processes polling for input is probably what has happened. I should give some attention to how Dolphin prevents that. Two things that come to mind are raising the priority of a new UI thread to create a modal event loop, and (which Pharo almost certainly does too) starting a new UI thread when needed.
My TimedEvaluator class has headless and "with progres" subclasses. The latter will need some porting, and perhaps the headless one should simply block, or at least do so in Pharo.
Terminating the UI thread seems a little harsh, but that might be what is needed.
Sure it is what debugger does when you closing its window - it terminating the process you currently debugging. Nothing harsh or wrong and nothing to worry about (usually). :)
Another option might be to suspend the old UI thread, start the new one, and then undo the damage at the end.
There are is a little damage which is done when you doing that - mainly the event which is currently handled is lost, but since your intent to terminate the current process, as a result of event handling, nothing wrong with it. As for the rest , when you start a new UI process everything continues to work normally.
I don't know if you remember, but there was a DNU bug some months ago (probably) caused by 2 UI-processes being active for a short period of time, one nilling mouse state after the other had initiated mouse handling. At least that was the only explanation I could come up with,nobody replied whether the scenario I described was actually possible :) http://n2.nabble.com/-ANN--MouseOverHandler-refactoring-td3068941.html#a3098... Cheers, Henry
Henry, I'm impressed - that sure sounds like my situation. Do you know what to do about it? :) This is another situation when it would be nice to have the errors appended to the log vs. replacing the file contents. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Henrik Johansen Sent: Monday, August 17, 2009 3:41 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain? On Aug 16, 2009, at 4:57 17PM, Igor Stasenko wrote:
2009/8/16 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Sig,
Two UI processes polling for input is probably what has happened. I should give some attention to how Dolphin prevents that. Two things that come to mind are raising the priority of a new UI thread to create a modal event loop, and (which Pharo almost certainly does too) starting a new UI thread when needed.
My TimedEvaluator class has headless and "with progres" subclasses. The latter will need some porting, and perhaps the headless one should simply block, or at least do so in Pharo.
Terminating the UI thread seems a little harsh, but that might be what is needed.
Sure it is what debugger does when you closing its window - it terminating the process you currently debugging. Nothing harsh or wrong and nothing to worry about (usually). :)
Another option might be to suspend the old UI thread, start the new one, and then undo the damage at the end.
There are is a little damage which is done when you doing that - mainly the event which is currently handled is lost, but since your intent to terminate the current process, as a result of event handling, nothing wrong with it. As for the rest , when you start a new UI process everything continues to work normally.
I don't know if you remember, but there was a DNU bug some months ago (probably) caused by 2 UI-processes being active for a short period of time, one nilling mouse state after the other had initiated mouse handling. At least that was the only explanation I could come up with,nobody replied whether the scenario I described was actually possible :) http://n2.nabble.com/-ANN--MouseOverHandler-refactoring-td3068941.html#a3098... Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
The first thing that crossed my mind back then was that instead of writing: aBool := Project spawnNewProcessIfThisIsUI: process. ** Code that runs before "aSuspendedProcess" is actually suspended ** process suspend. you can change it to: newUIProcess :=Project newProcessIfThisIsUI: process. ** Old code before process suspend ** [process suspend. newUIProcess ifNotNil: [: uip | uip resume] ] fork. where newProcessIfThisIsUI returns an unresumed version of spawnNewUIProcess, or nil if process wasn't UI process. Which of course is both ugly and error prone for the senders, and why I hoped someone would come up with a better way. It did seem to work though, as far as I can remember :) Cheers, Henry On 17.08.2009 18:47, csrabak@bol.com.br wrote:
This is a feature I vote for, too.
Em 17/08/2009 13:14, *Schwab,Wilhelm K < bschwab@anest.ufl.edu >* escreveu:
Henry,
I'm impressed - that sure sounds like my situation. Do you know what to do about it? :)
This is another situation when it would be nice to have the errors appended to the log vs. replacing the file contents.
Bill
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (6)
-
csrabak＠bol.com.br -
Henrik Johansen -
Henrik Sperre Johansen
-
Igor Stasenko -
Schwab,Wilhelm K -
Stéphane Ducasse