Hi everyone, is there any chapter on multithreading in Pharo books? If not maybe Iâll write something about that, but any material will be useful for me right now.
Hello, What do you mean by multithreading ? Do you mean Semaphore and Process, Cog Multithreading, the Island VM plugin ? 2013/11/20 Yuriy Tymchuk <yuriy.tymchuk@me.com>
Hi everyone, is there any chapter on multithreading in Pharo books? If not maybe Iâll write something about that, but any material will be useful for me right now.
Iâm not proficient in multithreading, but I think that Iâm looking for Semaphore and Process. Things that I implement take a very long time to run, and I canât do anything else during that time or even cancel them. So I guess they should run in a separate process which I can achieve with #fork. But as I start to work with that I want to know all the rest that can be useful. uko On 20 Nov 2013, at 19:21, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
What do you mean by multithreading ? Do you mean Semaphore and Process, Cog Multithreading, the Island VM plugin ?
2013/11/20 Yuriy Tymchuk <yuriy.tymchuk@me.com> Hi everyone, is there any chapter on multithreading in Pharo books? If not maybe Iâll write something about that, but any material will be useful for me right now.
So what you are looking for is Process and semaphores. This is not multithreading in the default Pharo VM + image, currently our semaphore/process management is not multithreaded, but executes all the process in the same thread. What happens basically is that you will run several processes in 1 thread with different priorities, and processes with highest priorities will be executed first. This is very good for your case, because if you put your task in another process with lower priority than the UI process, each time you will trigger a UI interaction the secondary process will be temporarily stopped to execute your UI interaction. (see #forkAt: Process userBackgroundPriority) Seemingly there's no chapter about Process and semaphores yet but Stef is planning to write one. The other alternatives are to use CogMT, a version of the Cog VM with real multithreading for FFI (but I think it will not work easily with your case) or the island VM plugin, which seemingly is an actor based multithreading system in Squeak/Pharo (however there is only 1 project that successfully uses it, which is the one of 3DICC). 2013/11/20 Yuriy Tymchuk <yuriy.tymchuk@me.com>
Iâm not proficient in multithreading, but I think that Iâm looking for Semaphore and Process. Things that I implement take a very long time to run, and I canât do anything else during that time or even cancel them. So I guess they should run in a separate process which I can achieve with #fork. But as I start to work with that I want to know all the rest that can be useful.
uko
On 20 Nov 2013, at 19:21, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
What do you mean by multithreading ? Do you mean Semaphore and Process, Cog Multithreading, the Island VM plugin ?
2013/11/20 Yuriy Tymchuk <yuriy.tymchuk@me.com>
Hi everyone, is there any chapter on multithreading in Pharo books? If not maybe Iâll write something about that, but any material will be useful for me right now.
On 20 Nov 2013, at 20:58, Clément Bera <bera.clement@gmail.com> wrote:
So what you are looking for is Process and semaphores.
This is not multithreading in the default Pharo VM + image, currently our semaphore/process management is not multithreaded, but executes all the process in the same thread.
Ouch. Do you know if this is planned for any milestone?
What happens basically is that you will run several processes in 1 thread with different priorities, and processes with highest priorities will be executed first. This is very good for your case, because if you put your task in another process with lower priority than the UI process, each time you will trigger a UI interaction the secondary process will be temporarily stopped to execute your UI interaction.
(see #forkAt: Process userBackgroundPriority)
Seemingly there's no chapter about Process and semaphores yet but Stef is planning to write one.
The other alternatives are to use CogMT, a version of the Cog VM with real multithreading for FFI (but I think it will not work easily with your case) or the island VM plugin, which seemingly is an actor based multithreading system in Squeak/Pharo (however there is only 1 project that successfully uses it, which is the one of 3DICC).
2013/11/20 Yuriy Tymchuk <yuriy.tymchuk@me.com> Iâm not proficient in multithreading, but I think that Iâm looking for Semaphore and Process. Things that I implement take a very long time to run, and I canât do anything else during that time or even cancel them. So I guess they should run in a separate process which I can achieve with #fork. But as I start to work with that I want to know all the rest that can be useful.
uko
On 20 Nov 2013, at 19:21, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
What do you mean by multithreading ? Do you mean Semaphore and Process, Cog Multithreading, the Island VM plugin ?
2013/11/20 Yuriy Tymchuk <yuriy.tymchuk@me.com> Hi everyone, is there any chapter on multithreading in Pharo books? If not maybe Iâll write something about that, but any material will be useful for me right now.
On 21 Nov 2013, at 12:33, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 20 Nov 2013, at 20:58, Clément Bera <bera.clement@gmail.com> wrote:
So what you are looking for is Process and semaphores.
This is not multithreading in the default Pharo VM + image, currently our semaphore/process management is not multithreaded, but executes all the process in the same thread.
Ouch. Do you know if this is planned for any milestone?
It is a problem that is far from simple to solve. Just defining a milestone will not help anything. Marcus
Python is in the same situation, what Python coders do is span processes, in this case OS process which is an instance of python interpreter , the advantage of an OSprocess is that it can run on a separate core in case you have a multicore cpu. This way you get true concurrency. However OS process are isolated so you will have to make them communicate via sockets or pipes. Python has such libraries to facilitate easy communication between processes. In case of Pharo you would be opening Pharo headless several times, one instance for each concurrent task you want. This way you will get non blocking code and able to take advantage of all the cores of your cpu. On Thu, Nov 21, 2013 at 1:38 PM, Marcus Denker <marcus.denker@inria.fr>wrote:
On 21 Nov 2013, at 12:33, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 20 Nov 2013, at 20:58, Clément Bera <bera.clement@gmail.com> wrote:
So what you are looking for is Process and semaphores.
This is not multithreading in the default Pharo VM + image, currently our semaphore/process management is not multithreaded, but executes all the process in the same thread.
Ouch. Do you know if this is planned for any milestone?
It is a problem that is far from simple to solve. Just defining a milestone will not help anything.
Marcus
On 21 Nov 2013, at 12:33, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 20 Nov 2013, at 20:58, Clément Bera <bera.clement@gmail.com> wrote:
So what you are looking for is Process and semaphores.
This is not multithreading in the default Pharo VM + image, currently our semaphore/process management is not multithreaded, but executes all the process in the same thread.
Ouch. Do you know if this is planned for any milestone?
This is not necessarily bad. Erlang, king of multiprocessing, has a pretty slow VM and runs its own scheduling. Like Erlang, it should be possible to have really a lot of Processes. Not that there are no (important) differences, of course.
What happens basically is that you will run several processes in 1 thread with different priorities, and processes with highest priorities will be executed first. This is very good for your case, because if you put your task in another process with lower priority than the UI process, each time you will trigger a UI interaction the secondary process will be temporarily stopped to execute your UI interaction.
(see #forkAt: Process userBackgroundPriority)
Seemingly there's no chapter about Process and semaphores yet but Stef is planning to write one.
The other alternatives are to use CogMT, a version of the Cog VM with real multithreading for FFI (but I think it will not work easily with your case) or the island VM plugin, which seemingly is an actor based multithreading system in Squeak/Pharo (however there is only 1 project that successfully uses it, which is the one of 3DICC).
2013/11/20 Yuriy Tymchuk <yuriy.tymchuk@me.com> Iâm not proficient in multithreading, but I think that Iâm looking for Semaphore and Process. Things that I implement take a very long time to run, and I canât do anything else during that time or even cancel them. So I guess they should run in a separate process which I can achieve with #fork. But as I start to work with that I want to know all the rest that can be useful.
uko
On 20 Nov 2013, at 19:21, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
What do you mean by multithreading ? Do you mean Semaphore and Process, Cog Multithreading, the Island VM plugin ?
2013/11/20 Yuriy Tymchuk <yuriy.tymchuk@me.com> Hi everyone, is there any chapter on multithreading in Pharo books? If not maybe Iâll write something about that, but any material will be useful for me right now.
On 20 Nov 2013, at 20:58, Clément Bera <bera.clement@gmail.com> wrote:
So what you are looking for is Process and semaphores.
This is not multithreading in the default Pharo VM + image, currently our semaphore/process management is not multithreaded, but executes all the process in the same thread. What happens basically is that you will run several processes in 1 thread with different priorities, and processes with highest priorities will be executed first. This is very good for your case, because if you put your task in another process with lower priority than the UI process, each time you will trigger a UI interaction the secondary process will be temporarily stopped to execute your UI interaction.
(see #forkAt: Process userBackgroundPriority)
One more thing: how do I synchronise? For example I want two async processes, but when they both finish I want to execute something. Eg. return merged data generated by processes.
Seemingly there's no chapter about Process and semaphores yet but Stef is planning to write one.
The other alternatives are to use CogMT, a version of the Cog VM with real multithreading for FFI (but I think it will not work easily with your case) or the island VM plugin, which seemingly is an actor based multithreading system in Squeak/Pharo (however there is only 1 project that successfully uses it, which is the one of 3DICC).
2013/11/20 Yuriy Tymchuk <yuriy.tymchuk@me.com> Iâm not proficient in multithreading, but I think that Iâm looking for Semaphore and Process. Things that I implement take a very long time to run, and I canât do anything else during that time or even cancel them. So I guess they should run in a separate process which I can achieve with #fork. But as I start to work with that I want to know all the rest that can be useful.
uko
On 20 Nov 2013, at 19:21, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
What do you mean by multithreading ? Do you mean Semaphore and Process, Cog Multithreading, the Island VM plugin ?
2013/11/20 Yuriy Tymchuk <yuriy.tymchuk@me.com> Hi everyone, is there any chapter on multithreading in Pharo books? If not maybe Iâll write something about that, but any material will be useful for me right now.
On 2013-11-21, at 15:56, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 20 Nov 2013, at 20:58, Clément Bera <bera.clement@gmail.com> wrote:
So what you are looking for is Process and semaphores.
This is not multithreading in the default Pharo VM + image, currently our semaphore/process management is not multithreaded, but executes all the process in the same thread. What happens basically is that you will run several processes in 1 thread with different priorities, and processes with highest priorities will be executed first. This is very good for your case, because if you put your task in another process with lower priority than the UI process, each time you will trigger a UI interaction the secondary process will be temporarily stopped to execute your UI interaction.
(see #forkAt: Process userBackgroundPriority)
One more thing: how do I synchronise? For example I want two async processes, but when they both finish I want to execute something. Eg. return merged data generated by processes.
Semaphores are your friends: semaphore := Semaphore new. [ ... First Job ... semaphore signal. ] fork. [ ... Second Job ... semaphore signal. ] fork. "consume to signals, aka. pause this thread until both jobs have finished" semaphore wait; wait.
participants (6)
-
Camillo Bruni -
Clément Bera -
kilon alios -
Marcus Denker -
Sven Van Caekenberghe -
Yuriy Tymchuk