Le 18/04/2015 19:57, Ben Coman a écrit :
On 18/04/2015 3:36 pm, "Esteban Lorenzano" <[email protected] <mailto:[email protected]>> wrote: > > So… “multithread” is a complicated issue. Pharo as most Smalltalks is designed thinking is as monolithic so if you are trying to make the image to work in different processes… it will not be easy at all :) The holy grail of multithreaded seems to be functional programing, where essentially the benefit comes from threads not modifying global state. The problem with our monolithic system is that you are often (if not always) modifying global state. Worker threads can be written that avoid explicitly modifying global state, but your worker call a method that calls a method that calls a method that unnoticed by you modifies global state. This has been the source of a number of bugs I've hunted down in Pharo (e.g. Transcript; Monticello repository filter). You have to dig deep to notice these and I have wondered if somehow there could be some system help to make such cases fail-early such that any assignment to any instance variable generates an exception. You could turn this on for worker threads to ensure they can't inadvertently affect the monolithic assumptions of the main system. Of course the worker threads need to deal with transient global state, but you are in control writing new code with this in mind -- but it protects reuse of existing monolithic code. What would it take to get such a feature?
Reuse the transactional memory stuff for Pharo which already exist? Thierry
Cheers -ben
