[Pharo-project] Pharo windows hanging ...
Igor Stasenko wrote:
This is because all do-its executed in process, which responsible from handling UI events. To avoid 'hanging' you can just do like following: [ do what you need ] fork.
Oh, yes! Then i commanded a Full GC. I had to clean some 16 MByte Smalltalk stuff on my Notebook. 15 Seconds I had to wait, till my keystrokes and mouse events were accepted back again by Pharo GUI. Well, in the meantime, the seaside process was unresponsive. Ok, no real problem. Customers can wait and I have my coffee breaks ;-) World Wide Wait with Seaside Servers on Pharo ... Sorry, no access to The Salty Spitoon .... (not yet) ;-) Have fun, Guido Stepken
2009/4/22 stepken <stepken@web.de>:
Igor Stasenko wrote:
 > This is because all do-its executed in process, which responsible from  > handling UI events.  > To avoid 'hanging' you can just do like following:  > [ do what you need ] fork.
Oh, yes!
Then i commanded a Full GC. I had to clean some 16 MByte Smalltalk stuff on my Notebook. 15 Seconds I had to wait, till my keystrokes and mouse events were accepted back again by Pharo GUI.
Well, in the meantime, the seaside process was unresponsive.
Ok, no real problem. Customers can wait and I have my coffee breaks ;-)
World Wide Wait with Seaside Servers on Pharo ...
this is not a particularily Pharo issue. Squeak VM employs a green threading model which means that only a single process can be active at a single point of time, and the order how they proceed are determined by scheduler. I understand the reasons of your sarcasm, yes.. its not perfect! Many, many code in Squeak (and consequently in Pharo) is naively implemented (including UI), and without concurrency in mind. But this is not the only UI framework which hates the concurrency - take a look at "groundbreaking" Mac OS :)
Sorry, no access to The Salty Spitoon .... (not yet) ;-)
Have fun, Guido Stepken
_______________________________________________ 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 Apr 22, 2009, at 11:38 AM, Igor Stasenko wrote:
But this is not the only UI framework which hates the concurrency - take a look at "groundbreaking" Mac OS :)
yes, but they have a nice mechanism for dealing with this when a worker thread wants to update the UI - (void)performSelectorOnMainThread:(SEL)aSelector withObject:(id)arg waitUntilDone:(BOOL)wait; Is there a Squeak equivalent for getting something invoked on the main UI thread? -Todd Blanchard
On Wed, Apr 22, 2009 at 09:17:12PM -0700, Eagle Offshore wrote:
On Apr 22, 2009, at 11:38 AM, Igor Stasenko wrote:
But this is not the only UI framework which hates the concurrency - take a look at "groundbreaking" Mac OS :)
yes, but they have a nice mechanism for dealing with this when a worker thread wants to update the UI
- (void)performSelectorOnMainThread:(SEL)aSelector withObject:(id)arg waitUntilDone:(BOOL)wait;
Is there a Squeak equivalent for getting something invoked on the main UI thread?
WorldState class>>addDeferredUIMessage:
Ok, I have to comment since i'm up to my neck with alligators over performSelectorOnMainThread: In fact just this evening 4 hours toasted to document a bug with this call with Apple for tomorrow. (a) people don't realize with the carbon os-x vm we run on the Main Thread and poll for os-x events that then get dispatch to the squeak vm event handlers. This leads to the interesting jerky non-responsive feedback you get with the VM when you accidently kill the morphic polling loop, since we aren't servicing the UI event polling fast enough since we are using a fallback 1/2 second ancient piece of code that in the past looked for the interrupt key. (b) If you use the Unix os-x vm, that spins the squeak thread off as a background task, now if you do UI related work via FFI then you die. (c) performSelectorOnMainThread: has lots of interesting bugs on the iPhone, especially if you try to do view animation with it. (d) the iphone vm runs as a background thread, but deadlocks with UIWebView between it and the main thread, are interesting, all solvable, but interesting. Fortunately in the future we can migrate back to (a) on the iPhone. (e) if you run on the Main Thread then you need something to handle event callbacks from the UI when you call the UI to service a UI event. Fortunately this has been worked out and is easier than (d) Frankly (a), (b), (c) and did I mention (d) are serious complications I could do without. On 22-Apr-09, at 9:17 PM, Eagle Offshore wrote:
On Apr 22, 2009, at 11:38 AM, Igor Stasenko wrote:
But this is not the only UI framework which hates the concurrency - take a look at "groundbreaking" Mac OS :)
yes, but they have a nice mechanism for dealing with this when a worker thread wants to update the UI
- (void)performSelectorOnMainThread:(SEL)aSelector withObject: (id)arg waitUntilDone:(BOOL)wait;
Is there a Squeak equivalent for getting something invoked on the main UI thread?
-Todd Blanchard _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
John M McIntosh wrote:
Ok, I have to comment since i'm up to my neck with alligators over performSelectorOnMainThread: In fact just this evening 4 hours toasted to document a bug with this call with Apple for tomorrow.
(a) people don't realize with the carbon os-x vm we run on the Main Thread and poll for os-x events that then get dispatch to the squeak vm event handlers. This leads to the interesting jerky non-responsive feedback you get with the VM when you accidently kill the morphic polling loop, since we aren't servicing the UI event polling fast enough since we are using a fallback 1/2 second ancient piece of code that in the past looked for the interrupt key.
This is gone in the new event sensor design. Michael
I assume c and d will get fixed (since doing animation from worker threads is pretty much the point). b - well of course you can't do UI work from FFI - you're not on the UI thread - unless you call performSelectorOnMainThread:... from there. a - I dunno - it seems like squeak's vm ought to do most work not on the UI thread except for UI things but the runtime models aren't exactly what I'd call fundamentally compatible since Cocoa wants to own the runloop and just call you back now and then via delegates or notifications. I have a Cocoa MIDI/CoreAudio AudioUnits host that makes heavy use of coreaudio (which ends up spawning a few dozen threads) but still animates pictures of keyboards, sound meters, etc.... in near real time and does it all by calling performSelectorOnMainThread:... and it all works like a charm so long as I remember to invoke the graphics update routines via performSelectorOnMainThread:. I would like to try out the new Cocoa bridge on a Mac at some point and see what can be done with it. -Todd Blanchard On Apr 22, 2009, at 10:30 PM, John M McIntosh wrote:
Ok, I have to comment since i'm up to my neck with alligators over performSelectorOnMainThread: In fact just this evening 4 hours toasted to document a bug with this call with Apple for tomorrow.
(a) people don't realize with the carbon os-x vm we run on the Main Thread and poll for os-x events that then get dispatch to the squeak vm event handlers. This leads to the interesting jerky non-responsive feedback you get with the VM when you accidently kill the morphic polling loop, since we aren't servicing the UI event polling fast enough since we are using a fallback 1/2 second ancient piece of code that in the past looked for the interrupt key.
(b) If you use the Unix os-x vm, that spins the squeak thread off as a background task, now if you do UI related work via FFI then you die.
(c) performSelectorOnMainThread: has lots of interesting bugs on the iPhone, especially if you try to do view animation with it.
(d) the iphone vm runs as a background thread, but deadlocks with UIWebView between it and the main thread, are interesting, all solvable, but interesting. Fortunately in the future we can migrate back to (a) on the iPhone.
(e) if you run on the Main Thread then you need something to handle event callbacks from the UI when you call the UI to service a UI event. Fortunately this has been worked out and is easier than (d)
Frankly (a), (b), (c) and did I mention (d) are serious complications I could do without.
On 22-Apr-09, at 9:17 PM, Eagle Offshore wrote:
On Apr 22, 2009, at 11:38 AM, Igor Stasenko wrote:
But this is not the only UI framework which hates the concurrency - take a look at "groundbreaking" Mac OS :)
yes, but they have a nice mechanism for dealing with this when a worker thread wants to update the UI
- (void)performSelectorOnMainThread:(SEL)aSelector withObject: (id)arg waitUntilDone:(BOOL)wait;
Is there a Squeak equivalent for getting something invoked on the main UI thread?
-Todd Blanchard _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- = = = = = ====================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 23-Apr-09, at 12:40 AM, Eagle Offshore wrote:
I assume c and d will get fixed (since doing animation from worker threads is pretty much the point).
(c) yes and no, the animation part no, because it's a timing issue and switching processes messes with graphics's engines view of things. (d) no UIWebView is non-concurrent object, in future OS perhaps touching it from a background thread leads to a fatal exception (on purpose).
b - well of course you can't do UI work from FFI - you're not on the UI thread - unless you call performSelectorOnMainThread:... from there.
no developers want to do that, also it's hard to determine what that is, using quicktime just to open a quicktime file not even display it? is that UI. Well it wasn't in the past, is now.
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
You are not forced to use pharo and you can send code once you signed the license agreement. talking is easier than doing. Stef (a Doer).
Igor Stasenko wrote:
This is because all do-its executed in process, which responsible from handling UI events. To avoid 'hanging' you can just do like following: [ do what you need ] fork.
Oh, yes!
Then i commanded a Full GC. I had to clean some 16 MByte Smalltalk stuff on my Notebook. 15 Seconds I had to wait, till my keystrokes and mouse events were accepted back again by Pharo GUI.
Well, in the meantime, the seaside process was unresponsive.
Ok, no real problem. Customers can wait and I have my coffee breaks ;-)
World Wide Wait with Seaside Servers on Pharo ...
Sorry, no access to The Salty Spitoon .... (not yet) ;-)
Have fun, Guido Stepken
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (7)
-
David T. Lewis -
Eagle Offshore -
Igor Stasenko -
John M McIntosh -
Michael Rueger -
stepken -
Stéphane Ducasse