[Pharo-project] Hello everyone!

Igor Stasenko siguctua at gmail.com
Mon Sep 8 23:05:41 EDT 2008

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
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.

More information about the Pharo-dev mailing list