2008/9/9 Bill Schwab <[EMAIL PROTECTED]>: > Igor, > > THANKS for thinking about concurrency. Processes need to be sound. Re > #ensure:, we might consider "unsuspending/unterminating" the process > long enough to run the block. That way the block runs in the thread it > expects, after which, there would hopefully be nothing else to do?? >
The problem with exceptions, that some exception handling code can simply ignore exception and continue to run - from same or from different point. This will lead to situation, that issued termination request will not guarantee that process will be terminated. This is what i think we don't want to see, because its very controversial. That's why i thinking that using exceptions is not the way to go. Maybe, we could use a trick by overriding #pass and #return methods in ProcessTerminateException class, to ensure that it will continue unwinding stack. But how to deal with following code: [ ..... ] ensure: [ ^self ]. [ .... ] on: Error do: [:ex | ^ self ]. > Re using exceptions to indicate impending termination, that sounds more > like an event (potentially many consumers). If it is simply a > system-level trick, then I suppose it's fine. > Yes, it can be pushed into process to indicate termination, so user code could use it to differentiate behavior on it. But actual termination and stack unwinding should be separate thing, which should guarantee that process will be terminated > Bill > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: [EMAIL PROTECTED] > Tel: (352) 273-6785 > FAX: (352) 392-7029 > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
