[Pharo-project] Hello everyone!
stephane.ducasse at inria.fr
Tue Sep 9 16:04:13 EDT 2008
for the concurrency may be something good would be to start writing
instead of fixing the current one. I know that when we rewrite with
get a lot of bugs
but at least prototyping something would be useful. I'm really nul in
but I know it should be good.
On Sep 9, 2008, at 9:41 AM, Adrian Lienhard wrote:
> Welcome, Igor!
> Would you also be interested to help maintain the VM? Recently on
> this list we've discussed whether it would make sense to have our
> own Pharo VM. For instance, to have the Freetype Plugin by default,
> but maybe also for larger improvements like the ones that come from
> On Sep 9, 2008, at 05:05 , Igor Stasenko wrote:
>> 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
>> 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
>> 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
>> 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
>> - 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
>> 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
>> 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
>> 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
>> 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,
>> could use notification.
>> As you can see, there is more questions than answers :)
>> Best regards,
>> Igor Stasenko AKA sig.
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
More information about the Pharo-dev