Sig, If you give us "overlapped calls," we'll make a statue of you. I'll bring the chissels :)
On sockets, I'm not terribly worried about the blocking part: what I don't want is for the whole image to go under because of mis-typed URL or something. In short, I'm worried about too much blocking, not the absense of it. Bill -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Igor Stasenko Sent: Monday, May 10, 2010 6:21 PM To: [email protected] Subject: Re: [Pharo-project] Single threaded Pharo IDE? 2010/5/11 Schwab,Wilhelm K <[email protected]>: > Andrei > Having do-its block the UI is a feature, especially since you can > explicitly fork a new (Smalltalk) process to do the work. What is > **NOT** acceptable (and I fear I will discover is "easy" to cause to > happen) is for DNS and socket operations that have been forked to block the > main thread. > someone still has to do that for you, i.e. wait for a completion of blocking operation. > Dolphin has a feature called overlapped calls that allow external > functions to be executed on a new OS thread specifically to avoid > hanging the entire image. There are restrictions and disclaimers even > then, and the default behavior is to block the UI. > Btw, its good that you mentioned this feature. Given that i have a full control, what happens with NativeBoost, i could create a native thread to serve for handling such 'overlapped' calls, and at image side, it will just put a process, which made a call into a waitable state, while other processes could still continue to run. > Bill > > ________________________________ > From: [email protected] > [mailto:[email protected]] On Behalf Of > Andrei Stebakov > Sent: Monday, May 10, 2010 5:31 PM > To: [email protected] > Cc: Adrian Lienhard > Subject: Re: [Pharo-project] Single threaded Pharo IDE? > > > > 2010/5/10 Mariano Martinez Peck <[email protected]> >> >> >> 2010/5/10 Andrei Stebakov <[email protected]> >>> >>> >>> I just started to use Pharo 1.0. So please bear with me since I may >>> not fully understand the full concept of the IDE. Sometimes the >>> whole IDE freezes indefinitely. >> >> Welcome ! we hope you enjoy ;) >> >>> >>> So questions: >>> 1) Looks like evaluating anything from the Workspace freezes the >>> whole UI for the time of execution. Is it a bug or a feature? >> >> More or less. Pharo has a green thread implementation. I will tell >> you what I understand. Green threads means, there is only ONE OS >> thread, and then, internally (in Smalltalk) there exists their own >> threads, scheduler, priorities, etc. The UI is just a process that is >> running, with a certain priority. Go to the world menu, then "Tools" >> -> "Process Browser". There you will see all the current processes >> with their priorities. You can notice the UI process. >> > But you must agree that it still looks fishy when your whole UI blocks > when you execute something lengthy (like new package install)... > Well, if the majority of Pharo users think that it's OK who am I to argue? > ;) > > >> So...whatever you do here, it will be done inside that process. If >> you do normal things, then yes, I guess the UI freezes. However, you >> way want to launch another thread to do what you want and with a >> lower priority than the UI. >> >> Do this test: open a workspace and a transcript. In the workspace, >> evaluate: >> >> [ 1000 timesRepeat: [Transcript show: 'mariano'; cr] ] forkAt: >> Processor userBackgroundPriority >> >> there, you will see that you are able to use the ide, while the block >> of writing to Transcript is working "at the same time". >> >> Here the most important message is forkAt: . fork just fork the >> block with the standard priority ("Processor activePriority"). If you >> want to specify the priority, you have to use forkAt: > > Yes, the [ HTTPSocket httpGet: 'http://www.pharo-project.org/home'] forkAt: > Processor userBackgroundPriority doesn't block the UI anymore... > If it's the way to go, shouldn't we have a "special non-blocking" > Workspace which does exactly this (or have an option to run your > Workspace command with a background priority)? > >> >> >>> >>> 2) Sometimes executing something freezes the UI indefinitely. Is >>> there a way to cancel the operation (other than restarting the image)? >>> Strangely in my case the IDE froze on evaluating HTTPSocket httpGet: >>> 'http://www.pharo-project.org/home' >>> >> >> Yes, Sockets are an example where sometimes they block the whole image. >> Are you behind a proxy ? do you have a timeout error after a while ? >> I have just tested and it also freezes for me in Mac OS. I have no idea. >> Maybe other can help. > > If I execute HTTPSocket httpGet: 'http://www.pharo-project.org/home'. > in a Workspace having a Transcript window open, I got a never-ending > messages in the Transcript window like: > "redirecting to http://www.cmsbox.com/errors/hostnotfound.html";. > Yes, I am behind a firewall, but other urls work with the same command. > > >> >> But yes, usually (sometimes it doesn't work) there is a combination >> of keys that send a system interruption. Check this links: >> >> http://wiki.squeak.org/squeak/899 >> http://wiki.squeak.org/squeak/1542 >> > Great! Alt-. works. >> >> BTW Adrian, I think this deserves a FAQ entry as it has been asked >> several times. >> >> Cheers >> >> Mariano >> >>> >>> Thank you, >>> Andrei >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
