yes thats correct. I am using python threads , (they are green threads too like pharo) to make my blocking socket not block the overall execution of code.
Dont need fork on the pharo side because I send the message and I expect an immediate reply so the blocking is too short for the user to notice. I was giving OSProcess a try using the fork methods for thisProcess but it looks like it requires an XDisplayControlPlugin , which is weird that it does not just bass the block as argument to the new instance of pharo. of course it can be done already with command: method and passing any code you want to run to the new pharo instance together with a message to close image . it will return an object with the variable runState to #running while your code in the pharo instance runs and then #complete as soon as it finishes to take advantage of multiple cores and true concurency. On Mon, Aug 4, 2014 at 4:46 PM, Guillermo Polito <[email protected]> wrote: > Wait, if your computations make use of I/O, wouldn't *forking* allow to > take advantage when a green thread is blocked for example, writing a > socket? :) > > > On Mon, Aug 4, 2014 at 2:53 PM, Levente Uzonyi <[email protected]> wrote: > >> On Mon, 4 Aug 2014, Frank Shearar wrote: >> >> On 4 August 2014 09:38, Clément Bera <[email protected]> wrote: >>> >>>> >>>> >>>> >>>> 2014-08-04 10:17 GMT+02:00 Yuriy Tymchuk <[email protected]>: >>>> >>>>> >>>>> Hi guys, >>>>> >>>>> I have a script that runs very slow and does a lot of non dependent >>>>> operation of a collection. I wander if I can speed it up by making it >>>>> run in >>>>> another process, because as far as I understand everything runs on a >>>>> single >>>>> thread, so I guess this won’t save me. >>>>> >>>>> I don't think forking can speed up anything. >>>> >>> >>> But that's only because we're single-threaded, hence single-cored. If >>> we had a VM that handle multiple threads (like if we resuscitated >>> Andreas' and Igor's Hydra work), then forking _would_ speed things up. >>> But that would raise another huge issue, namely the shared state >>> nature of the image. >>> >> >> Hydra works differently. It's basically running multiple images from a >> single VM, and provides channels between images for communication (like in >> Erlang). There's no shared state at all between images, and one image can >> only use one core just like now. >> It's also possible to use multiple cores by spawning new VMs. IIRC >> OSProcess has some support for this. >> >> >> Levente >> >> >> >>> So perhaps forking _would_ help if your computations were big enough >>> to justify the cost of spinning up a clone image, like David Lewis' >>> recent work. >>> >>> frank >>> >>> Usually the best solution is to profile your operation with the >>>> Profiler, >>>> then implement differently costly operations, either by removing >>>> object/block creations in smalltalk if this is possible, else by >>>> implementing costly operations in C and bind them like that: >>>> http://clementbera.wordpress.com/2013/06/19/optimizing- >>>> pharo-to-c-speed-with-nativeboost-ffi/ >>>> >>>> >>>> >>>> >>>> >>>>> Uko >>>>> >>>> >>>> >>>> >>> >
