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.
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
