NativeBoost / Callbacks and Multithreading

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

NativeBoost / Callbacks and Multithreading

Nicolai Hess
 
Hi,

I've tried to build a pharovm with multithread support. I changed the config in the
pharo generator.image to use the cogmt config and was able to build a vm.
But this vm crashes on startup. (windows7)

Is this the right way and did anyone got this to work (windows or linux)?

And can this work to make NB callbacks working for multithreaded libraries.

(I made some simple bindings for the gstreamer lib with NB, this works
for simple calls (create element/change state). But I guess this won't work
for any gstreamer function that requests a callback that may b e called from
a different thread)

Would this be the right way to do:
- build a vm with MT support
- guard the NB callback entry/leave code with the ownVM()/disownVM() call.

Or is there more to do.

Thanks in advance


nicolai


Reply | Threaded
Open this post in threaded view
|

Re: NativeBoost / Callbacks and Multithreading (Eliot: This is not just NB, we need you here :P)

EstebanLM
 
Hi, 

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 :)
Time ago Eliot did a prototype (more than a prototype in fact, but still far from “production ready”) to have Threaded FFI and I’m quite sure this is the way to go, at least as a 1st milestone. 

I already have a process building this experimental VM:


(No idea why windows build failed last two times… this can be a random fail).

I do not remember exactly the changes needed in the image to take advantage of it… it was just an instVar in Process, I think, but then FFI package was adapted to take advantage of this… no idea where it is now (if is already incorporated in latest FFI, which we have).

Then, after this… I imagine the callback mechanism can be adapted to work in multithread environments but probably we will need something like isolates from Dart to provide some degree of multithread processing without killing the image (but I’m just thinking in loud here, this can be a really bad idea, and probably there are other ways to do this better… I will let Eliot to explain better). 

TL;DR: Start for the CogMTVM, is the way to go.

cheers, 
Esteban

On 17 Apr 2015, at 09:06, Nicolai Hess <[hidden email]> wrote:

Hi,

I've tried to build a pharovm with multithread support. I changed the config in the
pharo generator.image to use the cogmt config and was able to build a vm.
But this vm crashes on startup. (windows7)

Is this the right way and did anyone got this to work (windows or linux)?

And can this work to make NB callbacks working for multithreaded libraries.

(I made some simple bindings for the gstreamer lib with NB, this works
for simple calls (create element/change state). But I guess this won't work
for any gstreamer function that requests a callback that may b e called from
a different thread)

Would this be the right way to do:
- build a vm with MT support
- guard the NB callback entry/leave code with the ownVM()/disownVM() call.

Or is there more to do.

Thanks in advance


nicolai



Reply | Threaded
Open this post in threaded view
|

Re: NativeBoost / Callbacks and Multithreading (Eliot: This is not just NB, we need you here :P)

Nicolai Hess
 
Thank you Esteban,

2015-04-18 9:36 GMT+02:00 Esteban Lorenzano <[hidden email]>:
 
Hi, 

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 :)
Time ago Eliot did a prototype (more than a prototype in fact, but still far from “production ready”) to have Threaded FFI and I’m quite sure this is the way to go, at least as a 1st milestone. 

I already have a process building this experimental VM:


But this one does not include NativeBoost support. Do we have a build with MT and NB?
 

(No idea why windows build failed last two times… this can be a random fail).

I do not remember exactly the changes needed in the image to take advantage of it… it was just an instVar in Process, I think, but then FFI package was adapted to take advantage of this… no idea where it is now (if is already incorporated in latest FFI, which we have).

Then, after this… I imagine the callback mechanism can be adapted to work in multithread environments but probably we will need something like isolates from Dart to provide some degree of multithread processing without killing the image (but I’m just thinking in loud here, this can be a really bad idea, and probably there are other ways to do this better… I will let Eliot to explain better). 

TL;DR: Start for the CogMTVM, is the way to go.

cheers, 
Esteban

On 17 Apr 2015, at 09:06, Nicolai Hess <[hidden email]> wrote:

Hi,

I've tried to build a pharovm with multithread support. I changed the config in the
pharo generator.image to use the cogmt config and was able to build a vm.
But this vm crashes on startup. (windows7)

Is this the right way and did anyone got this to work (windows or linux)?

And can this work to make NB callbacks working for multithreaded libraries.

(I made some simple bindings for the gstreamer lib with NB, this works
for simple calls (create element/change state). But I guess this won't work
for any gstreamer function that requests a callback that may b e called from
a different thread)

Would this be the right way to do:
- build a vm with MT support
- guard the NB callback entry/leave code with the ownVM()/disownVM() call.

Or is there more to do.

Thanks in advance


nicolai





Reply | Threaded
Open this post in threaded view
|

Re: NativeBoost / Callbacks and Multithreading (Eliot: This is not just NB, we need you here :P)

Eliot Miranda-2
 
Hi Nicolai,

    I'm rather excited that you're interested in this.  Perhaps we (you, Esteban, Clément and I) could meet in a google hangout to discuss soon?

As Esteban said I was able to demonstrate threaded calls on Mac.  CoInterpreterMT is the subclass of CoInterpreter that adds support for threading. But the code is out-of-date.  So some work is needed to get back to where I was.  But to have someone focused on this is the key.  I don't think we have someone with the cycles yet and if you're that person (and can talk to Esteban, Clément and I, and maybe Ronie and Doug McPherson and Thierry) then I'm sure we can get it working soon.  Spur has the necessary pinning support for example.

Eliot (phone)

On Apr 18, 2015, at 9:24 AM, Nicolai Hess <[hidden email]> wrote:

Thank you Esteban,

2015-04-18 9:36 GMT+02:00 Esteban Lorenzano <[hidden email]>:
 
Hi, 

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 :)
Time ago Eliot did a prototype (more than a prototype in fact, but still far from “production ready”) to have Threaded FFI and I’m quite sure this is the way to go, at least as a 1st milestone. 

I already have a process building this experimental VM:


But this one does not include NativeBoost support. Do we have a build with MT and NB?
 

(No idea why windows build failed last two times… this can be a random fail).

I do not remember exactly the changes needed in the image to take advantage of it… it was just an instVar in Process, I think, but then FFI package was adapted to take advantage of this… no idea where it is now (if is already incorporated in latest FFI, which we have).

Then, after this… I imagine the callback mechanism can be adapted to work in multithread environments but probably we will need something like isolates from Dart to provide some degree of multithread processing without killing the image (but I’m just thinking in loud here, this can be a really bad idea, and probably there are other ways to do this better… I will let Eliot to explain better). 

TL;DR: Start for the CogMTVM, is the way to go.

cheers, 
Esteban

On 17 Apr 2015, at 09:06, Nicolai Hess <[hidden email]> wrote:

Hi,

I've tried to build a pharovm with multithread support. I changed the config in the
pharo generator.image to use the cogmt config and was able to build a vm.
But this vm crashes on startup. (windows7)

Is this the right way and did anyone got this to work (windows or linux)?

And can this work to make NB callbacks working for multithreaded libraries.

(I made some simple bindings for the gstreamer lib with NB, this works
for simple calls (create element/change state). But I guess this won't work
for any gstreamer function that requests a callback that may b e called from
a different thread)

Would this be the right way to do:
- build a vm with MT support
- guard the NB callback entry/leave code with the ownVM()/disownVM() call.

Or is there more to do.

Thanks in advance


nicolai





Reply | Threaded
Open this post in threaded view
|

Re: NativeBoost / Callbacks and Multithreading (Eliot: This is not just NB, we need you here :P)

stepharo
In reply to this post by Nicolai Hess
 
I think that the idea of eliot is independent from NB but use FFI.
Esteban will resume his task to use NB syntax for FFI and NB as a back-end of the UnifiedFFI.

Stef

Le 18/4/15 18:24, Nicolai Hess a écrit :
 


Thank you Esteban,

2015-04-18 9:36 GMT+02:00 Esteban Lorenzano <[hidden email]>:
 
Hi, 

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 :)
Time ago Eliot did a prototype (more than a prototype in fact, but still far from “production ready”) to have Threaded FFI and I’m quite sure this is the way to go, at least as a 1st milestone. 

I already have a process building this experimental VM:


But this one does not include NativeBoost support. Do we have a build with MT and NB?
 

(No idea why windows build failed last two times… this can be a random fail).

I do not remember exactly the changes needed in the image to take advantage of it… it was just an instVar in Process, I think, but then FFI package was adapted to take advantage of this… no idea where it is now (if is already incorporated in latest FFI, which we have).

Then, after this… I imagine the callback mechanism can be adapted to work in multithread environments but probably we will need something like isolates from Dart to provide some degree of multithread processing without killing the image (but I’m just thinking in loud here, this can be a really bad idea, and probably there are other ways to do this better… I will let Eliot to explain better). 

TL;DR: Start for the CogMTVM, is the way to go.

cheers, 
Esteban

On 17 Apr 2015, at 09:06, Nicolai Hess <[hidden email]> wrote:

Hi,

I've tried to build a pharovm with multithread support. I changed the config in the
pharo generator.image to use the cogmt config and was able to build a vm.
But this vm crashes on startup. (windows7)

Is this the right way and did anyone got this to work (windows or linux)?

And can this work to make NB callbacks working for multithreaded libraries.

(I made some simple bindings for the gstreamer lib with NB, this works
for simple calls (create element/change state). But I guess this won't work
for any gstreamer function that requests a callback that may b e called from
a different thread)

Would this be the right way to do:
- build a vm with MT support
- guard the NB callback entry/leave code with the ownVM()/disownVM() call.

Or is there more to do.

Thanks in advance


nicolai






Reply | Threaded
Open this post in threaded view
|

Re: NativeBoost / Callbacks and Multithreading (Eliot: This is not just NB, we need you here :P)

Eliot Miranda-2
 
Hi Stef,

On Apr 18, 2015, at 10:13 AM, stepharo <[hidden email]> wrote:

I think that the idea of eliot is independent from NB but use FFI.
Esteban will resume his task to use NB syntax for FFI and NB as a back-end of the UnifiedFFI.

I hope we can revise this slightly to agree with the back end that Ronie, Clément and I propose, which is to use the unsafe bytecodes in Sista/Scorch to include Ronie's lowcode and do the marshaling, avoiding NB.  This gives us platform independence, the ability to function in the interpreter (the Sista interpreter can execute these bytecodes too), and security, since when jitted the code lives in the code zone which we can secure, and avoid making the whole heap executable.  Maybe you can discuss with Clément when he returns.


Stef

Le 18/4/15 18:24, Nicolai Hess a écrit :
 


Thank you Esteban,

2015-04-18 9:36 GMT+02:00 Esteban Lorenzano <[hidden email]>:
 
Hi, 

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 :)
Time ago Eliot did a prototype (more than a prototype in fact, but still far from “production ready”) to have Threaded FFI and I’m quite sure this is the way to go, at least as a 1st milestone. 

I already have a process building this experimental VM:


But this one does not include NativeBoost support. Do we have a build with MT and NB?
 

(No idea why windows build failed last two times… this can be a random fail).

I do not remember exactly the changes needed in the image to take advantage of it… it was just an instVar in Process, I think, but then FFI package was adapted to take advantage of this… no idea where it is now (if is already incorporated in latest FFI, which we have).

Then, after this… I imagine the callback mechanism can be adapted to work in multithread environments but probably we will need something like isolates from Dart to provide some degree of multithread processing without killing the image (but I’m just thinking in loud here, this can be a really bad idea, and probably there are other ways to do this better… I will let Eliot to explain better). 

TL;DR: Start for the CogMTVM, is the way to go.

cheers, 
Esteban

On 17 Apr 2015, at 09:06, Nicolai Hess <[hidden email]> wrote:

Hi,

I've tried to build a pharovm with multithread support. I changed the config in the
pharo generator.image to use the cogmt config and was able to build a vm.
But this vm crashes on startup. (windows7)

Is this the right way and did anyone got this to work (windows or linux)?

And can this work to make NB callbacks working for multithreaded libraries.

(I made some simple bindings for the gstreamer lib with NB, this works
for simple calls (create element/change state). But I guess this won't work
for any gstreamer function that requests a callback that may b e called from
a different thread)

Would this be the right way to do:
- build a vm with MT support
- guard the NB callback entry/leave code with the ownVM()/disownVM() call.

Or is there more to do.

Thanks in advance


nicolai






Reply | Threaded
Open this post in threaded view
|

Re: NativeBoost / Callbacks and Multithreading (Eliot: This is not just NB, we need you here :P)

EstebanLM
 

On 18 Apr 2015, at 19:36, Eliot Miranda <[hidden email]> wrote:

Hi Stef,

On Apr 18, 2015, at 10:13 AM, stepharo <[hidden email]> wrote:

I think that the idea of eliot is independent from NB but use FFI.
Esteban will resume his task to use NB syntax for FFI and NB as a back-end of the UnifiedFFI.

I hope we can revise this slightly to agree with the back end that Ronie, Clément and I propose, which is to use the unsafe bytecodes in Sista/Scorch to include Ronie's lowcode and do the marshaling, avoiding NB.  This gives us platform independence, the ability to function in the interpreter (the Sista interpreter can execute these bytecodes too), and security, since when jitted the code lives in the code zone which we can secure, and avoid making the whole heap executable.  Maybe you can discuss with Clément when he returns.

yes, we are in sync here. 
our idea is to keep NB syntax, because is very good (and for backward compatibility), but to adopt your approach :)

Esteban



Stef

Le 18/4/15 18:24, Nicolai Hess a écrit :
 


Thank you Esteban,

2015-04-18 9:36 GMT+02:00 Esteban Lorenzano <[hidden email]>:
 
Hi, 

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 :)
Time ago Eliot did a prototype (more than a prototype in fact, but still far from “production ready”) to have Threaded FFI and I’m quite sure this is the way to go, at least as a 1st milestone. 

I already have a process building this experimental VM:


But this one does not include NativeBoost support. Do we have a build with MT and NB?
 

(No idea why windows build failed last two times… this can be a random fail).

I do not remember exactly the changes needed in the image to take advantage of it… it was just an instVar in Process, I think, but then FFI package was adapted to take advantage of this… no idea where it is now (if is already incorporated in latest FFI, which we have).

Then, after this… I imagine the callback mechanism can be adapted to work in multithread environments but probably we will need something like isolates from Dart to provide some degree of multithread processing without killing the image (but I’m just thinking in loud here, this can be a really bad idea, and probably there are other ways to do this better… I will let Eliot to explain better). 

TL;DR: Start for the CogMTVM, is the way to go.

cheers, 
Esteban

On 17 Apr 2015, at 09:06, Nicolai Hess <[hidden email]> wrote:

Hi,

I've tried to build a pharovm with multithread support. I changed the config in the
pharo generator.image to use the cogmt config and was able to build a vm.
But this vm crashes on startup. (windows7)

Is this the right way and did anyone got this to work (windows or linux)?

And can this work to make NB callbacks working for multithreaded libraries.

(I made some simple bindings for the gstreamer lib with NB, this works
for simple calls (create element/change state). But I guess this won't work
for any gstreamer function that requests a callback that may b e called from
a different thread)

Would this be the right way to do:
- build a vm with MT support
- guard the NB callback entry/leave code with the ownVM()/disownVM() call.

Or is there more to do.

Thanks in advance


nicolai







Reply | Threaded
Open this post in threaded view
|

Re: NativeBoost / Callbacks and Multithreading (Eliot: This is not just NB, we need you here :P)

Ben Coman
In reply to this post by EstebanLM
 


On 18/04/2015 3:36 pm, "Esteban Lorenzano" <[hidden email]> 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?

Cheers -ben

Reply | Threaded
Open this post in threaded view
|

Re: NativeBoost / Callbacks and Multithreading (Eliot: This is not just NB, we need you here :P)

stephane ducasse-2
In reply to this post by Eliot Miranda-2
 

On 18 Apr 2015, at 19:36, Eliot Miranda <[hidden email]> wrote:

Hi Stef,

On Apr 18, 2015, at 10:13 AM, stepharo <[hidden email]> wrote:

I think that the idea of eliot is independent from NB but use FFI.
Esteban will resume his task to use NB syntax for FFI and NB as a back-end of the UnifiedFFI.

I hope we can revise this slightly to agree with the back end that Ronie, Clément and I propose, which is to use the unsafe bytecodes in Sista/Scorch to include Ronie's lowcode and do the marshaling, avoiding NB.  This gives us platform independence, the ability to function in the interpreter (the Sista interpreter can execute these bytecodes too), and security, since when jitted the code lives in the code zone which we can secure, and avoid making the whole heap executable.  Maybe you can discuss with Clément when he returns.

yes we do not want to be bound to NB. (what I menat with NB as a back-end of the UnifiedFFI was that if people want to use NB as a back-end they should be able to do it).
If Igor maintains it and port it to 64 bits we do not want to be against. 
What we need is a version of FFI that understand NB syntax running so that we can ship Spur.

Stef



Stef

Le 18/4/15 18:24, Nicolai Hess a écrit :
 


Thank you Esteban,

2015-04-18 9:36 GMT+02:00 Esteban Lorenzano <[hidden email]>:
 
Hi, 

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 :)
Time ago Eliot did a prototype (more than a prototype in fact, but still far from “production ready”) to have Threaded FFI and I’m quite sure this is the way to go, at least as a 1st milestone. 

I already have a process building this experimental VM:


But this one does not include NativeBoost support. Do we have a build with MT and NB?
 

(No idea why windows build failed last two times… this can be a random fail).

I do not remember exactly the changes needed in the image to take advantage of it… it was just an instVar in Process, I think, but then FFI package was adapted to take advantage of this… no idea where it is now (if is already incorporated in latest FFI, which we have).

Then, after this… I imagine the callback mechanism can be adapted to work in multithread environments but probably we will need something like isolates from Dart to provide some degree of multithread processing without killing the image (but I’m just thinking in loud here, this can be a really bad idea, and probably there are other ways to do this better… I will let Eliot to explain better). 

TL;DR: Start for the CogMTVM, is the way to go.

cheers, 
Esteban

On 17 Apr 2015, at 09:06, Nicolai Hess <[hidden email]> wrote:

Hi,

I've tried to build a pharovm with multithread support. I changed the config in the
pharo generator.image to use the cogmt config and was able to build a vm.
But this vm crashes on startup. (windows7)

Is this the right way and did anyone got this to work (windows or linux)?

And can this work to make NB callbacks working for multithreaded libraries.

(I made some simple bindings for the gstreamer lib with NB, this works
for simple calls (create element/change state). But I guess this won't work
for any gstreamer function that requests a callback that may b e called from
a different thread)

Would this be the right way to do:
- build a vm with MT support
- guard the NB callback entry/leave code with the ownVM()/disownVM() call.

Or is there more to do.

Thanks in advance


nicolai







Reply | Threaded
Open this post in threaded view
|

Re: NativeBoost / Callbacks and Multithreading (Eliot: This is not just NB, we need you here :P)

Eliot Miranda-2
In reply to this post by Ben Coman
 
Hi Ben,

On Apr 18, 2015, at 10:57 AM, Ben Coman <[hidden email]> wrote:


On 18/04/2015 3:36 pm, "Esteban Lorenzano" <[hidden email]> 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 goal here is very different.  The goal is not to build a multithreaded Smalltalk such that multiple processes execute concurrently on multiple cores or processors.  The goal is instead to allow the system to interact freely with multiple threads through the FFI.

The scheme allows any number of threads to run the VM but only one if them is running the system at any one time.  The scheme allows the VM to change thread on any FFI call, process switch or callback.  It makes it extremely cheap to release the VM on a callout so that every FFI call, even one to something trivial such as strlen, to be a release point.

On callout the thread performing the FFI call reads the value of the owningThreadID variable, zeros the variable and makes the callout.  When that thread returns from the FFI call it tries to conditionally set owningThreadID to its id if it is zero, but if it is non-zero, and therefore owned by some other thread, enters a wait state where the scheduler will give it back the VM at the next suitable opportunity.

The heartbeat checks for owningThreadID being zero, and if so, either an existing thread that is waiting, or a new thread if none are waiting, is scheduled and tries to own the VM by again attempting to conditionally set owningThreadID to its ID.

Processes can be bound to threads so that the system respects priorities and allows certain activities to happen on specific threads.  Callbacks from as-yet-unknown processes can be accepted.  The scheme, David Simmons' from his Smalltalk VMs, is relatively simple and extremely efficient.  But it's still non-trivial to develop and needs effort to realize.  My prototype hasn't been worked on for four years.  It is rusty.  But it'll work and work well.

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?

Cheers -ben

Reply | Threaded
Open this post in threaded view
|

Re: NativeBoost / Callbacks and Multithreading (Eliot: This is not just NB, we need you here :P)

Nicolai Hess
In reply to this post by Eliot Miranda-2
 


2015-04-18 18:35 GMT+02:00 Eliot Miranda <[hidden email]>:
 
Hi Nicolai,

    I'm rather excited that you're interested in this.  Perhaps we (you, Esteban, Clément and I) could meet in a google hangout to discuss soon?

As Esteban said I was able to demonstrate threaded calls on Mac.  CoInterpreterMT is the subclass of CoInterpreter that adds support for threading. But the code is out-of-date.  So some work is needed to get back to where I was.  But to have someone focused on this is the key.  I don't think we have someone with the cycles yet and if you're that person (and can talk to Esteban, Clément and I, and maybe Ronie and Doug McPherson and Thierry) then I'm sure we can get it working soon.  Spur has the necessary pinning support for example.

Well, I am not sure I can be a help :)
And I spend my main time for fixing issues in the core image.
But I would like to help if I can.

About the CoInterpreterMT, is it possible to get this working with the NB additions?
It would be great but it sounds too simple, but would it work if we use a MT VM with NB additions and
change the NB callback entry/leave code to make calls to ownVM and disownVM
(for callbacks defined in the main vm thread, but called by some native code in another thread) ?

I am not sure if we need spurs pinning support here, because the current NB implementation works without it.


 

Eliot (phone)

On Apr 18, 2015, at 9:24 AM, Nicolai Hess <[hidden email]> wrote:

Thank you Esteban,

2015-04-18 9:36 GMT+02:00 Esteban Lorenzano <[hidden email]>:
 
Hi, 

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 :)
Time ago Eliot did a prototype (more than a prototype in fact, but still far from “production ready”) to have Threaded FFI and I’m quite sure this is the way to go, at least as a 1st milestone. 

I already have a process building this experimental VM:


But this one does not include NativeBoost support. Do we have a build with MT and NB?
 

(No idea why windows build failed last two times… this can be a random fail).

I do not remember exactly the changes needed in the image to take advantage of it… it was just an instVar in Process, I think, but then FFI package was adapted to take advantage of this… no idea where it is now (if is already incorporated in latest FFI, which we have).

Then, after this… I imagine the callback mechanism can be adapted to work in multithread environments but probably we will need something like isolates from Dart to provide some degree of multithread processing without killing the image (but I’m just thinking in loud here, this can be a really bad idea, and probably there are other ways to do this better… I will let Eliot to explain better). 

TL;DR: Start for the CogMTVM, is the way to go.

cheers, 
Esteban

On 17 Apr 2015, at 09:06, Nicolai Hess <[hidden email]> wrote:

Hi,

I've tried to build a pharovm with multithread support. I changed the config in the
pharo generator.image to use the cogmt config and was able to build a vm.
But this vm crashes on startup. (windows7)

Is this the right way and did anyone got this to work (windows or linux)?

And can this work to make NB callbacks working for multithreaded libraries.

(I made some simple bindings for the gstreamer lib with NB, this works
for simple calls (create element/change state). But I guess this won't work
for any gstreamer function that requests a callback that may b e called from
a different thread)

Would this be the right way to do:
- build a vm with MT support
- guard the NB callback entry/leave code with the ownVM()/disownVM() call.

Or is there more to do.

Thanks in advance


nicolai







Reply | Threaded
Open this post in threaded view
|

Re: NativeBoost / Callbacks and Multithreading (Eliot: This is not just NB, we need you here :P)

Eliot Miranda-2
 
Hi Nicolai,

On Apr 19, 2015, at 3:36 AM, Nicolai Hess <[hidden email]> wrote:



2015-04-18 18:35 GMT+02:00 Eliot Miranda <[hidden email]>:
 
Hi Nicolai,

    I'm rather excited that you're interested in this.  Perhaps we (you, Esteban, Clément and I) could meet in a google hangout to discuss soon?

As Esteban said I was able to demonstrate threaded calls on Mac.  CoInterpreterMT is the subclass of CoInterpreter that adds support for threading. But the code is out-of-date.  So some work is needed to get back to where I was.  But to have someone focused on this is the key.  I don't think we have someone with the cycles yet and if you're that person (and can talk to Esteban, Clément and I, and maybe Ronie and Doug McPherson and Thierry) then I'm sure we can get it working soon.  Spur has the necessary pinning support for example.

Well, I am not sure I can be a help :)
And I spend my main time for fixing issues in the core image.
But I would like to help if I can.

Good, thanks!

About the CoInterpreterMT, is it possible to get this working with the NB additions? 

Of course, but NB has several issues
- it isn't cross-platform
- it isn't secure (it makes the entire heap executable)
- it is yet another JIT while we have a cross-platform one which can more easily integrate FFI marshaling code with Smalltalk code

It would be great but it sounds too simple, but would it work if we use a MT VM with NB additions and
change the NB callback entry/leave code to make calls to ownVM and disownVM
(for callbacks defined in the main vm thread, but called by some native code in another thread) ?

Hmmm are NB callbacks different from Alien callbacks?  IIRC, NB uses the Alien callback machinery.  Igor, did you reimplement callback entry fir NB or reuse my code?  If not, what was the motivation to not use the existing infrastructure?


I am not sure if we need spurs pinning support here, because the current NB implementation works without it.

What would happen if one made an FFI call that included a ByteArray passed by reference which is used by the called code as a buffer and that code called back and in the callback the GC ran and moved the buffer then?

What would happen if one made an FFI call that included a ByteArray passed by reference which is used by the called code as a buffer and a thread switch occurred and the system ran the GC which moved the buffer while the first thread was using the buffer?

Eliot (phone)


Eliot (phone)

On Apr 18, 2015, at 9:24 AM, Nicolai Hess <[hidden email]> wrote:

Thank you Esteban,

2015-04-18 9:36 GMT+02:00 Esteban Lorenzano <[hidden email]>:
 
Hi, 

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 :)
Time ago Eliot did a prototype (more than a prototype in fact, but still far from “production ready”) to have Threaded FFI and I’m quite sure this is the way to go, at least as a 1st milestone. 

I already have a process building this experimental VM:


But this one does not include NativeBoost support. Do we have a build with MT and NB?
 

(No idea why windows build failed last two times… this can be a random fail).

I do not remember exactly the changes needed in the image to take advantage of it… it was just an instVar in Process, I think, but then FFI package was adapted to take advantage of this… no idea where it is now (if is already incorporated in latest FFI, which we have).

Then, after this… I imagine the callback mechanism can be adapted to work in multithread environments but probably we will need something like isolates from Dart to provide some degree of multithread processing without killing the image (but I’m just thinking in loud here, this can be a really bad idea, and probably there are other ways to do this better… I will let Eliot to explain better). 

TL;DR: Start for the CogMTVM, is the way to go.

cheers, 
Esteban

On 17 Apr 2015, at 09:06, Nicolai Hess <[hidden email]> wrote:

Hi,

I've tried to build a pharovm with multithread support. I changed the config in the
pharo generator.image to use the cogmt config and was able to build a vm.
But this vm crashes on startup. (windows7)

Is this the right way and did anyone got this to work (windows or linux)?

And can this work to make NB callbacks working for multithreaded libraries.

(I made some simple bindings for the gstreamer lib with NB, this works
for simple calls (create element/change state). But I guess this won't work
for any gstreamer function that requests a callback that may b e called from
a different thread)

Would this be the right way to do:
- build a vm with MT support
- guard the NB callback entry/leave code with the ownVM()/disownVM() call.

Or is there more to do.

Thanks in advance


nicolai







Reply | Threaded
Open this post in threaded view
|

Re: NativeBoost / Callbacks and Multithreading (Eliot: This is not just NB, we need you here :P)

EstebanLM
 

On 20 Apr 2015, at 16:20, Eliot Miranda <[hidden email]> wrote:

Hi Nicolai,

On Apr 19, 2015, at 3:36 AM, Nicolai Hess <[hidden email]> wrote:



2015-04-18 18:35 GMT+02:00 Eliot Miranda <[hidden email]>:
 
Hi Nicolai,

    I'm rather excited that you're interested in this.  Perhaps we (you, Esteban, Clément and I) could meet in a google hangout to discuss soon?

As Esteban said I was able to demonstrate threaded calls on Mac.  CoInterpreterMT is the subclass of CoInterpreter that adds support for threading. But the code is out-of-date.  So some work is needed to get back to where I was.  But to have someone focused on this is the key.  I don't think we have someone with the cycles yet and if you're that person (and can talk to Esteban, Clément and I, and maybe Ronie and Doug McPherson and Thierry) then I'm sure we can get it working soon.  Spur has the necessary pinning support for example.

Well, I am not sure I can be a help :)
And I spend my main time for fixing issues in the core image.
But I would like to help if I can.

Good, thanks!

About the CoInterpreterMT, is it possible to get this working with the NB additions? 

Of course, but NB has several issues
- it isn't cross-platform
- it isn't secure (it makes the entire heap executable)
- it is yet another JIT while we have a cross-platform one which can more easily integrate FFI marshaling code with Smalltalk code

I will also add that in the future we are going to adopt FFI, so no reason to re-implement something with NB (talking about reimplement multithread FFI, here… in case is possible). 


It would be great but it sounds too simple, but would it work if we use a MT VM with NB additions and
change the NB callback entry/leave code to make calls to ownVM and disownVM
(for callbacks defined in the main vm thread, but called by some native code in another thread) ?

Hmmm are NB callbacks different from Alien callbacks?  IIRC, NB uses the Alien callback machinery.  Igor, did you reimplement callback entry fir NB or reuse my code?  If not, what was the motivation to not use the existing infrastructure?

No, is a different implementation (and like 10x slower, because it needs to do weird stuff with the heap)



I am not sure if we need spurs pinning support here, because the current NB implementation works without it.

What would happen if one made an FFI call that included a ByteArray passed by reference which is used by the called code as a buffer and that code called back and in the callback the GC ran and moved the buffer then?

What would happen if one made an FFI call that included a ByteArray passed by reference which is used by the called code as a buffer and a thread switch occurred and the system ran the GC which moved the buffer while the first thread was using the buffer?

yes… there is not so simple. In practice, NB uses a separate memory segment, but it has to copy from/to ByteArrays when asking for it. This is a major drawback  (in all previous FFI implementations, including NB) that will be fixed with pin objects… 

cheers, 
Esteban


Eliot (phone)


Eliot (phone)

On Apr 18, 2015, at 9:24 AM, Nicolai Hess <[hidden email]> wrote:

Thank you Esteban,

2015-04-18 9:36 GMT+02:00 Esteban Lorenzano <[hidden email]>:
 
Hi, 

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 :)
Time ago Eliot did a prototype (more than a prototype in fact, but still far from “production ready”) to have Threaded FFI and I’m quite sure this is the way to go, at least as a 1st milestone. 

I already have a process building this experimental VM:


But this one does not include NativeBoost support. Do we have a build with MT and NB?
 

(No idea why windows build failed last two times… this can be a random fail).

I do not remember exactly the changes needed in the image to take advantage of it… it was just an instVar in Process, I think, but then FFI package was adapted to take advantage of this… no idea where it is now (if is already incorporated in latest FFI, which we have).

Then, after this… I imagine the callback mechanism can be adapted to work in multithread environments but probably we will need something like isolates from Dart to provide some degree of multithread processing without killing the image (but I’m just thinking in loud here, this can be a really bad idea, and probably there are other ways to do this better… I will let Eliot to explain better). 

TL;DR: Start for the CogMTVM, is the way to go.

cheers, 
Esteban

On 17 Apr 2015, at 09:06, Nicolai Hess <[hidden email]> wrote:

Hi,

I've tried to build a pharovm with multithread support. I changed the config in the
pharo generator.image to use the cogmt config and was able to build a vm.
But this vm crashes on startup. (windows7)

Is this the right way and did anyone got this to work (windows or linux)?

And can this work to make NB callbacks working for multithreaded libraries.

(I made some simple bindings for the gstreamer lib with NB, this works
for simple calls (create element/change state). But I guess this won't work
for any gstreamer function that requests a callback that may b e called from
a different thread)

Would this be the right way to do:
- build a vm with MT support
- guard the NB callback entry/leave code with the ownVM()/disownVM() call.

Or is there more to do.

Thanks in advance


nicolai








Reply | Threaded
Open this post in threaded view
|

Re: NativeBoost / Callbacks and Multithreading (Eliot: This is not just NB, we need you here :P)

Nicolai Hess
In reply to this post by Eliot Miranda-2
 


2015-04-20 16:20 GMT+02:00 Eliot Miranda <[hidden email]>:
 
Hi Nicolai,

On Apr 19, 2015, at 3:36 AM, Nicolai Hess <[hidden email]> wrote:



2015-04-18 18:35 GMT+02:00 Eliot Miranda <[hidden email]>:
 
Hi Nicolai,

    I'm rather excited that you're interested in this.  Perhaps we (you, Esteban, Clément and I) could meet in a google hangout to discuss soon?

As Esteban said I was able to demonstrate threaded calls on Mac.  CoInterpreterMT is the subclass of CoInterpreter that adds support for threading. But the code is out-of-date.  So some work is needed to get back to where I was.  But to have someone focused on this is the key.  I don't think we have someone with the cycles yet and if you're that person (and can talk to Esteban, Clément and I, and maybe Ronie and Doug McPherson and Thierry) then I'm sure we can get it working soon.  Spur has the necessary pinning support for example.

Well, I am not sure I can be a help :)
And I spend my main time for fixing issues in the core image.
But I would like to help if I can.

Good, thanks!

About the CoInterpreterMT, is it possible to get this working with the NB additions? 

Of course, but NB has several issues
- it isn't cross-platform
- it isn't secure (it makes the entire heap executable)
- it is yet another JIT while we have a cross-platform one which can more easily integrate FFI marshaling code with Smalltalk code

I had some hard time fighting with old doc about FFI / uncertain state of current FFI (which version works with what VM ). And finally NB was
the one I find that works good with Pharo and has some very well examples and existing working projects.
I'll switch to whatever new FFI (without the above issues) will come after NB. But right now, I don't know what are my options, is
there anything else I can use?

 

It would be great but it sounds too simple, but would it work if we use a MT VM with NB additions and
change the NB callback entry/leave code to make calls to ownVM and disownVM
(for callbacks defined in the main vm thread, but called by some native code in another thread) ?

Hmmm are NB callbacks different from Alien callbacks?  IIRC, NB uses the Alien callback machinery.  Igor, did you reimplement callback entry fir NB or reuse my code?  If not, what was the motivation to not use the existing infrastructure?


I am not sure if we need spurs pinning support here, because the current NB implementation works without it.

What would happen if one made an FFI call that included a ByteArray passed by reference which is used by the called code as a buffer and that code called back and in the callback the GC ran and moved the buffer then?

What would happen if one made an FFI call that included a ByteArray passed by reference which is used by the called code as a buffer and a thread switch occurred and the system ran the GC which moved the buffer while the first thread was using the buffer?

Sure, but arent NB objects marked as ExternalObjects?
 

Eliot (phone)


Eliot (phone)

On Apr 18, 2015, at 9:24 AM, Nicolai Hess <[hidden email]> wrote:

Thank you Esteban,

2015-04-18 9:36 GMT+02:00 Esteban Lorenzano <[hidden email]>:
 
Hi, 

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 :)
Time ago Eliot did a prototype (more than a prototype in fact, but still far from “production ready”) to have Threaded FFI and I’m quite sure this is the way to go, at least as a 1st milestone. 

I already have a process building this experimental VM:


But this one does not include NativeBoost support. Do we have a build with MT and NB?
 

(No idea why windows build failed last two times… this can be a random fail).

I do not remember exactly the changes needed in the image to take advantage of it… it was just an instVar in Process, I think, but then FFI package was adapted to take advantage of this… no idea where it is now (if is already incorporated in latest FFI, which we have).

Then, after this… I imagine the callback mechanism can be adapted to work in multithread environments but probably we will need something like isolates from Dart to provide some degree of multithread processing without killing the image (but I’m just thinking in loud here, this can be a really bad idea, and probably there are other ways to do this better… I will let Eliot to explain better). 

TL;DR: Start for the CogMTVM, is the way to go.

cheers, 
Esteban

On 17 Apr 2015, at 09:06, Nicolai Hess <[hidden email]> wrote:

Hi,

I've tried to build a pharovm with multithread support. I changed the config in the
pharo generator.image to use the cogmt config and was able to build a vm.
But this vm crashes on startup. (windows7)

Is this the right way and did anyone got this to work (windows or linux)?

And can this work to make NB callbacks working for multithreaded libraries.

(I made some simple bindings for the gstreamer lib with NB, this works
for simple calls (create element/change state). But I guess this won't work
for any gstreamer function that requests a callback that may b e called from
a different thread)

Would this be the right way to do:
- build a vm with MT support
- guard the NB callback entry/leave code with the ownVM()/disownVM() call.

Or is there more to do.

Thanks in advance


nicolai









Reply | Threaded
Open this post in threaded view
|

Re: NativeBoost / Callbacks and Multithreading (Eliot: This is not just NB, we need you here :P)

EstebanLM
 

On 20 Apr 2015, at 16:35, Nicolai Hess <[hidden email]> wrote:



2015-04-20 16:20 GMT+02:00 Eliot Miranda <[hidden email]>:
 
Hi Nicolai,

On Apr 19, 2015, at 3:36 AM, Nicolai Hess <[hidden email]> wrote:



2015-04-18 18:35 GMT+02:00 Eliot Miranda <[hidden email]>:
 
Hi Nicolai,

    I'm rather excited that you're interested in this.  Perhaps we (you, Esteban, Clément and I) could meet in a google hangout to discuss soon?

As Esteban said I was able to demonstrate threaded calls on Mac.  CoInterpreterMT is the subclass of CoInterpreter that adds support for threading. But the code is out-of-date.  So some work is needed to get back to where I was.  But to have someone focused on this is the key.  I don't think we have someone with the cycles yet and if you're that person (and can talk to Esteban, Clément and I, and maybe Ronie and Doug McPherson and Thierry) then I'm sure we can get it working soon.  Spur has the necessary pinning support for example.

Well, I am not sure I can be a help :)
And I spend my main time for fixing issues in the core image. 
But I would like to help if I can.

Good, thanks!

About the CoInterpreterMT, is it possible to get this working with the NB additions? 

Of course, but NB has several issues
- it isn't cross-platform
- it isn't secure (it makes the entire heap executable)
- it is yet another JIT while we have a cross-platform one which can more easily integrate FFI marshaling code with Smalltalk code

I had some hard time fighting with old doc about FFI / uncertain state of current FFI (which version works with what VM ). And finally NB was
the one I find that works good with Pharo and has some very well examples and existing working projects. 
I'll switch to whatever new FFI (without the above issues) will come after NB. But right now, I don't know what are my options, is
there anything else I can use?

 

It would be great but it sounds too simple, but would it work if we use a MT VM with NB additions and
change the NB callback entry/leave code to make calls to ownVM and disownVM 
(for callbacks defined in the main vm thread, but called by some native code in another thread) ?

Hmmm are NB callbacks different from Alien callbacks?  IIRC, NB uses the Alien callback machinery.  Igor, did you reimplement callback entry fir NB or reuse my code?  If not, what was the motivation to not use the existing infrastructure?


I am not sure if we need spurs pinning support here, because the current NB implementation works without it.

What would happen if one made an FFI call that included a ByteArray passed by reference which is used by the called code as a buffer and that code called back and in the callback the GC ran and moved the buffer then?

What would happen if one made an FFI call that included a ByteArray passed by reference which is used by the called code as a buffer and a thread switch occurred and the system ran the GC which moved the buffer while the first thread was using the buffer?

Sure, but arent NB objects marked as ExternalObjects?

Not all. 
if you work with pointers, you’re ok because you just take the number representing the address. But as soon as you want to interact with the data pointed, you need a move into image (for example, into a ByteArray, or a String). That’s a copy function… 

Esteban

 

Eliot (phone)


Eliot (phone)

On Apr 18, 2015, at 9:24 AM, Nicolai Hess <[hidden email]> wrote:

Thank you Esteban,

2015-04-18 9:36 GMT+02:00 Esteban Lorenzano <[hidden email]>:
 
Hi, 

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 :)
Time ago Eliot did a prototype (more than a prototype in fact, but still far from “production ready”) to have Threaded FFI and I’m quite sure this is the way to go, at least as a 1st milestone. 

I already have a process building this experimental VM:


But this one does not include NativeBoost support. Do we have a build with MT and NB?
 

(No idea why windows build failed last two times… this can be a random fail).

I do not remember exactly the changes needed in the image to take advantage of it… it was just an instVar in Process, I think, but then FFI package was adapted to take advantage of this… no idea where it is now (if is already incorporated in latest FFI, which we have).

Then, after this… I imagine the callback mechanism can be adapted to work in multithread environments but probably we will need something like isolates from Dart to provide some degree of multithread processing without killing the image (but I’m just thinking in loud here, this can be a really bad idea, and probably there are other ways to do this better… I will let Eliot to explain better). 

TL;DR: Start for the CogMTVM, is the way to go.

cheers, 
Esteban

On 17 Apr 2015, at 09:06, Nicolai Hess <[hidden email]> wrote:

Hi, 

I've tried to build a pharovm with multithread support. I changed the config in the 
pharo generator.image to use the cogmt config and was able to build a vm.
But this vm crashes on startup. (windows7)

Is this the right way and did anyone got this to work (windows or linux)?

And can this work to make NB callbacks working for multithreaded libraries.

(I made some simple bindings for the gstreamer lib with NB, this works
for simple calls (create element/change state). But I guess this won't work
for any gstreamer function that requests a callback that may b e called from
a different thread)

Would this be the right way to do:
- build a vm with MT support
- guard the NB callback entry/leave code with the ownVM()/disownVM() call.

Or is there more to do.

Thanks in advance


nicolai