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 <guillermopolito@gmail.com> 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 <leves@elte.hu> wrote:
On Mon, 4 Aug 2014, Frank Shearar wrote:

On 4 August 2014 09:38, Cl��ment Bera <bera.clement@gmail.com> wrote:



2014-08-04 10:17 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk@me.com>:

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