[Pharo-project] Hello everyone!

Stéphane Ducasse stephane.ducasse at inria.fr
Tue Sep 9 16:04:13 EDT 2008


Igor

for the concurrency may be something good would be to start writing  
another library.
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  
concurrent programming
but I know it should be good.

Stef


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  
> Eliot.
>
> Cheers,
> Adrian
>
> 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
>> 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
>> Pharo-project at lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>





More information about the Pharo-dev mailing list