I just subscribed and want to say hello to this list. :) At ESUG we discussed with Stephane and Markus some things in Squeak (and consequently in Pharo), which really need an overlook and better implementation. Stephane asked me, to think about overlooking Processes and concurrency in its current state. First, i must say that it is very fragile part of system because most things written w/o concurrency in mind. Last year i seen many issues related to concurrency: Semaphore , Delay, Process, Scheduler. Some of them resolved, some of them resolved in an ugly and hackish way - mostly as workarounds of lacking critical VM primitives which should guarantee atomicity for different purposes, and some of them is not resolved at all. Some things, which i noted and which i like/not like, can be found in squeak-dev list. But i will repeat them here, in single place: - Process should assume that it is running in ideal environment (e.g. in parallel to another processes w/o any preemption). Every bit of code, which requires synchronization should be based/take into account this assumption. a process should have three discrete states: - suspended - when initially created. - running - when you invoke resume. - terminated - when process no longer running and can't be resumed. It is wrong to consider a process which waiting on semaphore signal as suspended process. (see http://bugs.squeak.org/view.php?id=6822). Process which waits on semaphore is actually performing an action, while , by definition, a suspended process can't perform any action. Concerning process termination, it is also a can of worms to deal with: - process termination means stop doing anything in requested process, but this going into conflict with exception handling mechanism. The conflict comes from two things like #ensure: and #ifCurtailed: . Such mechanisms used to ensure that some code will have chance to run under any circumstances, regardless of the state of computation. It is interesting, where such code should run? In a process which initiated a terminate request, or in process which needs to be terminated by request. Most valid, of course - to run them in a terminating process. The problem, however, how to achieve that. Someone suggested to throw an exception, like ProcessTerminateException to indicate that the given process is going to be terminated. Such thing is also going into conflict with different points of view: a Process termination is usual functionality, provided for use, so why it should be considered as exceptional? Maybe, to solve the conflicts, and avoid using exceptions in an arguable way, it would be better to add support of process termination notification. So, each time process is going to terminate, it can notify all interesting parties of such event. Then, instead of using #ensure: to free critical system resources, one could use notification. As you can see, there is more questions than answers :) -- Best regards, Igor Stasenko AKA sig.