[Pharo-project] Alien and callbacks from "foreign" threads?
Hi everybody, I am close to releasing JNIPort (http://jniport.wikispaces.com) for Pharo and Squeak. Almost everything works on both Mac OS X and Windows with one exception. I can attach a Java VM to Pharo/Squeak, I can send messages to Java objects and get results back, and even callbacks from Java to Smalltalk seem to work. The exception is that a callback from Java to Smalltalk which comes from a different thread leads to a crash of the Squeak VM. I have not been able to figure out what the problem is. There is a similar problem with a hook of the Java VM: one can register a callback function which is called whenever the Java VM produces output for stdout/stderr. With Pharo 1.1.1 on Mac OS X, using this hook works when the hook contains a "nil halt", and if I simply proceed in each of the notifiers. When I remove the halt or replace it by a Delay, the image freezes. In Squeak 4.1 on Windows, the behavior is different: the VM crashes. Does Alien support callbacks coming from a "foreign" thread? Or is this a limitation of Alien? Thanks in advance for any help, Joachim Geidel -- View this message in context: http://forum.world.st/Alien-and-callbacks-from-foreign-threads-tp3175989p317... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Not really an answer to your question, but Dale Rogerson's Inside COM is an excellent book (a must-have on its own) that might help with such topics. I suspect what Alien will need to do is something similar to Apartment Threading - maybe it already does. It has (thankfully??) been a long time, but I vaguely recall mutterings about sequencing calls through the message queue, and even marshaling data and interface pointers across thread boundaries. Maybe Hydra holds some helpful answers?? If you have truly free threaded Java, it would probably be possible to get into situations where an Apartment threaded server would deadlock due to the synchronization of calls - I know enough to ask the question but not enough to answer it. I await an interesting discussion among the experts. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Joachim Geidel [joachim.geidel@onlinehome.de] Sent: Wednesday, January 05, 2011 12:22 PM To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Alien and callbacks from "foreign" threads? Hi everybody, I am close to releasing JNIPort (http://jniport.wikispaces.com) for Pharo and Squeak. Almost everything works on both Mac OS X and Windows with one exception. I can attach a Java VM to Pharo/Squeak, I can send messages to Java objects and get results back, and even callbacks from Java to Smalltalk seem to work. The exception is that a callback from Java to Smalltalk which comes from a different thread leads to a crash of the Squeak VM. I have not been able to figure out what the problem is. There is a similar problem with a hook of the Java VM: one can register a callback function which is called whenever the Java VM produces output for stdout/stderr. With Pharo 1.1.1 on Mac OS X, using this hook works when the hook contains a "nil halt", and if I simply proceed in each of the notifiers. When I remove the halt or replace it by a Delay, the image freezes. In Squeak 4.1 on Windows, the behavior is different: the VM crashes. Does Alien support callbacks coming from a "foreign" thread? Or is this a limitation of Alien? Thanks in advance for any help, Joachim Geidel -- View this message in context: http://forum.world.st/Alien-and-callbacks-from-foreign-threads-tp3175989p317... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
I think any interoperability should have a reasonable limitations. Otherwise, there is no way how to guarantee the system stability. Squeak and Cog virtual machines can't run multiple native threads interpreting smalltalk code, which means that any callback(s) will be forced to be handled in single (VM) thread. Apparently callbacks from foreign threads require a special checks to be added to detect it and then serialize the call to vm thread. And therefore, handling callback in different thread will require a synchronization with it, which kills an idea of invoking callback from different thread in a first place. So, even if Alien will implement support of callbacks in non-VM thread(s), the value of such feature are questionable, because it simply kills the attempt(s) of foreign language to gain performance benefits through exploiting multithreading. Allowing to interpret smalltalk using multiple threads is another story - see RoarVM :) So, unless you running RoarVM, i don't see that it is reasonable to support cross-thread callbacks. -- Best regards, Igor Stasenko AKA sig.
On Wed, Jan 5, 2011 at 10:36 AM, Igor Stasenko <siguctua@gmail.com> wrote:
I think any interoperability should have a reasonable limitations. Otherwise, there is no way how to guarantee the system stability.
Squeak and Cog virtual machines can't run multiple native threads interpreting smalltalk code, which means that any callback(s) will be forced to be handled in single (VM) thread.
No. One can arrange to shae the VM between native threads just like Python, which is what I've done in my prototype.
Apparently callbacks from foreign threads require a special checks to be added to detect it and then serialize the call to vm thread.
No. One can arrange for the current thread to cede ownership to the foreign thread and allow it to run. With a two-evel scheduler one can still arrange to preserve Smalltalk process priorities and scheduling semantics. Essentially one assigns a priority to foreign callbacks and they get to run as soon as their priority is high enough to displace the priority of the current process (in whatever thread it may be). The scheme you're describing is one I implemented in VisualWorks and it is slow and clumsy. The scheme I'm now using is due to David Simmons and by comparison is lightweight and fast. But neither are simple.
And therefore, handling callback in different thread will require a synchronization with it, which kills an idea of invoking callback from different thread in a first place.
Nope.
So, even if Alien will implement support of callbacks in non-VM thread(s), the value of such feature are questionable, because it simply kills the attempt(s) of foreign language to gain performance benefits through exploiting multithreading.
I disagree.
Allowing to interpret smalltalk using multiple threads is another story - see RoarVM :)
That's not the only way to go. Python (and my Cog prototype) shares the VM amongst native threads and it is quite a lot simpler than implementing a concurrently-threaded VM.
So, unless you running RoarVM, i don't see that it is reasonable to support cross-thread callbacks.
Not at all. It's quite a reasonable thing to want to do, and is not beyond us. best Eliot
-- Best regards, Igor Stasenko AKA sig.
On 5 January 2011 20:07, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Wed, Jan 5, 2011 at 10:36 AM, Igor Stasenko <siguctua@gmail.com> wrote:
I think any interoperability should have a reasonable limitations. Otherwise, there is no way how to guarantee the system stability.
Squeak and Cog virtual machines can't run multiple native threads interpreting smalltalk code, which means that any callback(s) will be forced to be handled in single (VM) thread.
No. Â One can arrange to shae the VM between native threads just like Python, which is what I've done in my prototype.
i didn't said it can't, i just don't see a reason for doing that. Too much for it.
Apparently callbacks from foreign threads require a special checks to be added to detect it and then serialize the call to vm thread.
No. Â One can arrange for the current thread to cede ownership to the foreign thread and allow it to run. Â With a two-evel scheduler one can still arrange to preserve Smalltalk process priorities and scheduling semantics. Â Essentially one assigns a priority to foreign callbacks and they get to run as soon as their priority is high enough to displace the priority of the current process (in whatever thread it may be). The scheme you're describing is one I implemented in VisualWorks and it is slow and clumsy. Â The scheme I'm now using is due to David Simmons and by comparison is lightweight and fast. Â But neither are simple.
Sharing VM among multiple threads.. Okay.. but this is same. It doesn't eliminates a need of synchronizing with thread which currently 'owns' VM to obtain a control, which means you can't start handling callback immediately, that's why i told that it kills an idea of using multithreading. Again, i hope you realizing that there is a lot of situations, where this won't go. Suppose that i using some library which using a thread-local storage. How i could guarantee that all calls to this library will be made in same thread, in situation, when VM could run interpreter in any random thread, resulted because of need to handle callback from other library, not related to one that used by code related to my library? I don't see how it can be made 'automagically' without introducing an additional discipline in code, and without any notion of native threads at language side, where developer could enforce some rules, known by him. Otherwise an interoperability scheme which you introducing is mine field. Also, now you must check every single primitive which currently used by VM is thread safe, i.e. it can be invoked from any 'random' thread without leading to unwanted effect(s). Which is a good thing (oh and i did that in Hydra btw). I know very well that some OS(es) and some libraries don't like when you using their functions either from non-main process thread, or from multiple threads. (Btw, Johm told scary story about GUI and multithreading on Macs multiple times ;) ) So, before introducing such kind of sharing , you should take care about every single primitive which using OS-specific function(s) or using some external library, that it is safe to make a calls from random thread. So, the question remains open: is it worth spending so much efforts for such small outcome? :)
And therefore, handling callback in different thread will require a synchronization with it, which kills an idea of invoking callback from different thread in a first place.
Nope.
So, even if Alien will implement support of callbacks in non-VM thread(s), the value of such feature are questionable, because it simply kills the attempt(s) of foreign language to gain performance benefits through exploiting multithreading.
I disagree.
access to VM run-time are obviosly synchronous. And as long as it true, there is very small reason to use multiple threads. A simple example. Suppose you using a 3rd party library for setting up a socket server, which is a single call, accepting a pointer to function which will handle incoming connections. The external library takes care about rest itself: it using thread pool(s) for incoming connections and in this way distributing load among multiple native threads. Now, what will happen if you pass a smalltalk callback to it? I can elaborate that, but i think you know it yourself.
Allowing to interpret smalltalk using multiple threads is another story - see RoarVM :)
That's not the only way to go. Â Python (and my Cog prototype) shares the VM amongst native threads and it is quite a lot simpler than implementing a concurrently-threaded VM.
sure its simpler. but kills multithreading benefits :)
So, unless you running RoarVM, i don't see that it is reasonable to support cross-thread callbacks.
Not at all. Â It's quite a reasonable thing to want to do, and is not beyond us.
Yeah, it is painful to turn once non-thread aware VM into be thread aware and play nicely with other players on [mine] field :)
best Eliot
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On Wed, Jan 5, 2011 at 11:58 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 5 January 2011 20:07, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Wed, Jan 5, 2011 at 10:36 AM, Igor Stasenko <siguctua@gmail.com>
wrote:
I think any interoperability should have a reasonable limitations. Otherwise, there is no way how to guarantee the system stability.
Squeak and Cog virtual machines can't run multiple native threads interpreting smalltalk code, which means that any callback(s) will be forced to be handled in single (VM) thread.
No. One can arrange to shae the VM between native threads just like Python, which is what I've done in my prototype.
i didn't said it can't, i just don't see a reason for doing that. Too much for it.
What do you mean "too much for it"? It costs too much?
Apparently callbacks from foreign threads require a special checks to be added to detect it and then serialize the call to vm thread.
No. One can arrange for the current thread to cede ownership to the foreign thread and allow it to run. With a two-evel scheduler one can still arrange to preserve Smalltalk process priorities and scheduling semantics. Essentially one assigns a priority to foreign callbacks and they get to run as soon as their priority is high enough to displace the priority of the current process (in whatever thread it may be). The scheme you're describing is one I implemented in VisualWorks and it is slow and clumsy. The scheme I'm now using is due to David Simmons and by comparison is lightweight and fast. But neither are simple.
Sharing VM among multiple threads.. Okay.. but this is same. It doesn't eliminates a need of synchronizing with thread which currently 'owns' VM to obtain a control, which means you can't start handling callback immediately, that's why i told that it kills an idea of using multithreading.
That doesn't follow. he fact you can't release the VM immediately doesn't mean it can't happen very quickly, certainly quickly enough. Nothing happens instantaneously in a computer. Computations take time. Thread switches take time. But computers are fast. So I don't see that the idea of using multithreading is killed at all.
Again, i hope you realizing that there is a lot of situations, where this won't go. Suppose that i using some library which using a thread-local storage. How i could guarantee that all calls to this library will be made in same thread, in situation, when VM could run interpreter in any random thread, resulted because of need to handle callback from other library, not related to one that used by code related to my library?
Because my system allows one to bind a process to a specific thread so that you can guarantee which thread a computation will run in by reserving a process for that computation and binding it to the relevant thread. The process scheduler (remember this is now a two-level scheduler) takes care of switching threads when one switches processes.
I don't see how it can be made 'automagically' without introducing an additional discipline in code, and without any notion of native threads at language side, where developer could enforce some rules, known by him. Otherwise an interoperability scheme which you introducing is mine field.
If one has to interoperate with code that has threading constraints (such as your example above) then one needs to code to those constraints. To be able to code to those constraints there has to be some relevant mechanism. That relevant mechanism is implementable (I have implemented it). But I don't see what your argument is. The current non-threaded system doesn't provide any way of interacting with foreign threads directly, right? So interacting requires programming. Introducing threading into the VM makes things easier, not more difficult, no? Also, now you must check every single primitive which currently used
by VM is thread safe, i.e. it can be invoked from any 'random' thread without leading to unwanted effect(s). Which is a good thing (oh and i did that in Hydra btw).
Why?
I know very well that some OS(es) and some libraries don't like when you using their functions either from non-main process thread, or from multiple threads. (Btw, Johm told scary story about GUI and multithreading on Macs multiple times ;) )
So, before introducing such kind of sharing , you should take care about every single primitive which using OS-specific function(s) or using some external library, that it is safe to make a calls from random thread.
You certainly need to be able to control threading, yes. But you're being a bit of a Cassandra. Most primitives are the VM's own and they work fine whatever thread they're in. GUI activities can be restricted to the GUI thread. FFI calls can be marked as threaded or non-threaded. Porcesses can be bound to threads or free to run on any thread. So there's lots of control. The system doesn't collapse into chaos as soon as one introduces a thread.
So, the question remains open: is it worth spending so much efforts for such small outcome? :)
Small outcome? The ability to interact with multi-threaded libraries is a small outcome? The ability to perform non-blocking calls is a small outcome? We see things differently :) best Eliot
And therefore, handling callback in different thread will require a synchronization with it, which kills an idea of invoking callback from different thread in a first place.
Nope.
So, even if Alien will implement support of callbacks in non-VM thread(s), the value of such feature are questionable, because it simply kills the attempt(s) of foreign language to gain performance benefits through exploiting multithreading.
I disagree.
access to VM run-time are obviosly synchronous. And as long as it true, there is very small reason to use multiple threads.
A simple example. Suppose you using a 3rd party library for setting up a socket server, which is a single call, accepting a pointer to function which will handle incoming connections. The external library takes care about rest itself: it using thread pool(s) for incoming connections and in this way distributing load among multiple native threads. Now, what will happen if you pass a smalltalk callback to it?
I can elaborate that, but i think you know it yourself.
Allowing to interpret smalltalk using multiple threads is another story - see RoarVM :)
That's not the only way to go. Python (and my Cog prototype) shares the VM amongst native threads and it is quite a lot simpler than implementing a concurrently-threaded VM.
sure its simpler. but kills multithreading benefits :)
So, unless you running RoarVM, i don't see that it is reasonable to support cross-thread callbacks.
Not at all. It's quite a reasonable thing to want to do, and is not beyond us.
Yeah, it is painful to turn once non-thread aware VM into be thread aware and play nicely with other players on [mine] field :)
best Eliot
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On 5 January 2011 21:40, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Wed, Jan 5, 2011 at 11:58 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 5 January 2011 20:07, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Wed, Jan 5, 2011 at 10:36 AM, Igor Stasenko <siguctua@gmail.com> wrote:
I think any interoperability should have a reasonable limitations. Otherwise, there is no way how to guarantee the system stability.
Squeak and Cog virtual machines can't run multiple native threads interpreting smalltalk code, which means that any callback(s) will be forced to be handled in single (VM) thread.
No. Â One can arrange to shae the VM between native threads just like Python, which is what I've done in my prototype.
i didn't said it can't, i just don't see a reason for doing that. Too much for it.
What do you mean "too much for it"? Â It costs too much?
yes. too much for just 'callbacks'. I wouldn't bother about costs if it would be something bigger.. but if it just for callbacks, then its too much as to me. Don't take me wrong, it would be good to have: a thread-aware VM is step forward anyways :)
Apparently callbacks from foreign threads require a special checks to be added to detect it and then serialize the call to vm thread.
No. Â One can arrange for the current thread to cede ownership to the foreign thread and allow it to run. Â With a two-evel scheduler one can still arrange to preserve Smalltalk process priorities and scheduling semantics. Â Essentially one assigns a priority to foreign callbacks and they get to run as soon as their priority is high enough to displace the priority of the current process (in whatever thread it may be). The scheme you're describing is one I implemented in VisualWorks and it is slow and clumsy. Â The scheme I'm now using is due to David Simmons and by comparison is lightweight and fast. Â But neither are simple.
Sharing VM among multiple threads.. Okay.. but this is same. It doesn't eliminates a need of synchronizing with thread which currently 'owns' VM to obtain a control, which means you can't start handling callback immediately, that's why i told that it kills an idea of using multithreading.
That doesn't follow. Â he fact you can't release the VM immediately doesn't mean it can't happen very quickly, certainly quickly enough. Â Nothing happens instantaneously in a computer. Â Computations take time. Thread switches take time. Â But computers are fast. Â So I don't see that the idea of using multithreading is killed at all.
Can VM handle two callbacks in parallel? No? Case closed :) I just don't like that in certain scenarios VM will serve as a lobotomizer for any external libraries, which invented a highly sophisticated ways to do multiple things at one time. I can hear a future woes and whines about 'why it sooo fast in X , but soo sloww smalltalk' :) And of course, for manycore era (which is yet-yet not happen), we have to propose something completely different, because given solution simply won't scale. But that of course affects many other systems and languages not just our beloved one :)
Again, i hope you realizing that there is a lot of situations, where this won't go. Suppose that i using some library which using a thread-local storage. How i could guarantee that all calls to this library will be made in same thread, in situation, when VM could run interpreter in any random thread, resulted because of need to handle callback from other library, not related to one that used by code related to my library?
Because my system allows one to bind a process to a specific thread so that you can guarantee which thread a computation will run in by reserving a process for that computation and binding it to the relevant thread. Â The process scheduler (remember this is now a two-level scheduler) takes care of switching threads when one switches processes.
That's not really solves the problem. Nothing prevents me from using same primitive(s) in different processes, which could lead to fatal error(s). Of course it is better than nothing.. But this will mean introducing some discipline into smalltalk code (and Debugger and Process etc etc) which is an added price, once you putting threaded callbacks into the cart, regardless whether you currently using them in your code or not. I wouldn't bother, but then again, seeing in what appalling state Squeak's own thread safety and scheduling is, i'd say it will take a loong road before we get to something stable out of it :)
I don't see how it can be made 'automagically' without introducing an additional discipline in code, and without any notion of native threads at language side, where developer could enforce some rules, known by him. Otherwise an interoperability scheme which you introducing is mine field.
If one has to interoperate with code that has threading constraints (such as your example above) then one needs to code to those constraints. Â To be able to code to those constraints there has to be some relevant mechanism. Â That relevant mechanism is implementable (I have implemented it). Â But I don't see what your argument is. Â The current non-threaded system doesn't provide any way of interacting with foreign threads directly, right? Â So interacting requires programming. Â Introducing threading into the VM makes things easier, not more difficult, no?
It opens certain perspectives. Of course. About making things easier.. One good property of the concurrency mine-field, that its not magically disappears once you start using some pre-made uber-cool library. You either always following rules and write a concurrent code _everywhere_, or not.. and have an unwanted consequences. And any futile attempts to mask the complexity leads to even more frustration in the end :)
Also, now  you must check every single primitive which currently used by VM is thread safe, i.e. it can be invoked from any 'random' thread without leading to unwanted effect(s). Which is a good thing (oh and i did that in Hydra btw).
Why?
you asking why its good? because if you know if prim (or perhaps plugin) is thread safe, then you can use it in any thread :)
I know very well that some OS(es) and some libraries don't like when you using their functions either from non-main process thread, or from multiple threads. (Btw, Johm told scary story about GUI and multithreading on Macs multiple times ;) )
So, before introducing such kind of sharing , you should take care about every single primitive which using OS-specific function(s) or using some external library, that it is safe to make a calls from random thread.
You certainly need to be able to control threading, yes. Â But you're being a bit of a Cassandra. Â Â Most primitives are the VM's own and they work fine whatever thread they're in. Â GUI activities can be restricted to the GUI thread. Â FFI calls can be marked as threaded or non-threaded. Â Porcesses can be bound to threads or free to run on any thread. Â So there's lots of control. Â Â The system doesn't collapse into chaos as soon as one introduces a thread.
It doesn't collapse. Not at all. But it certainly becomes more brittle. Once (or if) you release the code, i will gladly show you some exploits, and of course would be happy if they won't break anything :)
So, the question remains open: is it worth spending so much efforts for such small outcome? :)
Small outcome? Â The ability to interact with multi-threaded libraries is a small outcome? Â The ability to perform non-blocking calls is a small outcome? Â We see things differently :)
I meant just callbacks. For threaded calls i think i would just introduce a native threads control into language and let developer to instruct VM, from which thread do a certain call(s). That's much cheaper because it doesn't requires big changes from VM side.
best Eliot
-- Best regards, Igor Stasenko AKA sig.
Igor Stasenko wrote:
Can VM handle two callbacks in parallel? No? Case closed :) I just don't like that in certain scenarios VM will serve as a lobotomizer for any external libraries, which invented a highly sophisticated ways to do multiple things at one time. I can hear a future woes and whines about 'why it sooo fast in X , but soo sloww smalltalk' :)
Igor, there are cases where foreign callbacks are needed and where this has nothing at all to do with performance or multi-core processors. I have already pointed out the case of monitoring a Java VM from a Smalltalk application which uses Java libraries. In this case, it's completely irrelevant what the performance is or whether the Smalltalk VM can handle two callbacks in parallel. Best regards, Joachim Geidel -- View this message in context: http://forum.world.st/Alien-and-callbacks-from-foreign-threads-tp3175989p317... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
eliot this sounds exciting. Explained what do you mean by prototype to joachim because it seems to me that he can be perfect beta tester :)
On Wed, Jan 5, 2011 at 10:36 AM, Igor Stasenko <siguctua@gmail.com> wrote: I think any interoperability should have a reasonable limitations. Otherwise, there is no way how to guarantee the system stability.
Squeak and Cog virtual machines can't run multiple native threads interpreting smalltalk code, which means that any callback(s) will be forced to be handled in single (VM) thread.
No. One can arrange to shae the VM between native threads just like Python, which is what I've done in my prototype.
Apparently callbacks from foreign threads require a special checks to be added to detect it and then serialize the call to vm thread.
No. One can arrange for the current thread to cede ownership to the foreign thread and allow it to run. With a two-evel scheduler one can still arrange to preserve Smalltalk process priorities and scheduling semantics. Essentially one assigns a priority to foreign callbacks and they get to run as soon as their priority is high enough to displace the priority of the current process (in whatever thread it may be).
The scheme you're describing is one I implemented in VisualWorks and it is slow and clumsy. The scheme I'm now using is due to David Simmons and by comparison is lightweight and fast. But neither are simple.
And therefore, handling callback in different thread will require a synchronization with it, which kills an idea of invoking callback from different thread in a first place.
Nope.
So, even if Alien will implement support of callbacks in non-VM thread(s), the value of such feature are questionable, because it simply kills the attempt(s) of foreign language to gain performance benefits through exploiting multithreading.
I disagree.
Allowing to interpret smalltalk using multiple threads is another story - see RoarVM :)
That's not the only way to go. Python (and my Cog prototype) shares the VM amongst native threads and it is quite a lot simpler than implementing a concurrently-threaded VM.
So, unless you running RoarVM, i don't see that it is reasonable to support cross-thread callbacks.
Not at all. It's quite a reasonable thing to want to do, and is not beyond us.
best Eliot
-- Best regards, Igor Stasenko AKA sig.
Igor, Igor Stasenko wrote:
So, unless you running RoarVM, i don't see that it is reasonable to support cross-thread callbacks.
VisualWorks and Dolphin both support foreign callbacks, using two very different implementations. Yes, it's not easy, as there are lots of ways to create deadlocks and faults etc. Chris Uppal's implementation of JNIPort for Dolphin came with a highly complicated http://metagnostic.dolphinmap.net/JNIPort/threading.html mechanism for deadlock prevention which is now also part of the ports of JNIPort to VisualWorks, Pharo and Squeak. However, there are situations where foreign callbacks are needed simply because the external libraries which are used have a multithreaded implementation. E.g., the callbacks for monitoring a Java VM (to monitor class loading, garbage collection etc.) will always come from a foreign thread, and this has nothing to do with performance. It's just the way it is. Another example (see screenshot at the end of the page): http://metagnostic.dolphinmap.net/JNIPort/callback-example-1.html http://metagnostic.dolphinmap.net/JNIPort/callback-example-1.html Best regards, Joachim Geidel -- View this message in context: http://forum.world.st/Alien-and-callbacks-from-foreign-threads-tp3175989p317... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Hi Joachim, On Wed, Jan 5, 2011 at 9:22 AM, Joachim Geidel <joachim.geidel@onlinehome.de
wrote:
Hi everybody,
I am close to releasing JNIPort (http://jniport.wikispaces.com) for Pharo and Squeak. Almost everything works on both Mac OS X and Windows with one exception. I can attach a Java VM to Pharo/Squeak, I can send messages to Java objects and get results back, and even callbacks from Java to Smalltalk seem to work.
The exception is that a callback from Java to Smalltalk which comes from a different thread leads to a crash of the Squeak VM. I have not been able to figure out what the problem is. There is a similar problem with a hook of the Java VM: one can register a callback function which is called whenever the Java VM produces output for stdout/stderr. With Pharo 1.1.1 on Mac OS X, using this hook works when the hook contains a "nil halt", and if I simply proceed in each of the notifiers. When I remove the halt or replace it by a Delay, the image freezes. In Squeak 4.1 on Windows, the behavior is different: the VM crashes.
Does Alien support callbacks coming from a "foreign" thread? Or is this a limitation of Alien?
That current version of Alien does /not/ support callbacks from foreign threads. I have a prototype that does support callbacks from foreign threasds and supports non-blocking callouts on arbitrary threads. Essentially the VM shares the VM between native threads such that only one thread can be running Smalltalk at any one time but that any number of natie thresds can share the VM. I demonstrated this to various people in ConcepcÃon during Smalltalks 2010. Are you interested in working with this prototype code? Pleaze let me know either way. I haven't sought permission to release this code yet but I would very much like to. I think there's value to Teleplace in my releasing it before we release it internally because it needs pounding on to bring up to production quality. If there's significant interest in this code I'll ask for permission to release it and see where we go from there.
Thanks in advance for any help, Joachim Geidel
-- View this message in context: http://forum.world.st/Alien-and-callbacks-from-foreign-threads-tp3175989p317... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Eliot Miranda-2 wrote:
That current version of Alien does /not/ support callbacks from foreign threads.
Aah, that explains a lot. ;-) Eliot Miranda-2 wrote:
I have a prototype that does support callbacks from foreign threasds and supports non-blocking callouts on arbitrary threads. ... Are you interested in working with this prototype code? Pleaze let me know either way. I haven't sought permission to release this code yet but I would very much like to. I think there's value to Teleplace in my releasing it before we release it internally because it needs pounding on to bring up to production quality. If there's significant interest in this code I'll ask for permission to release it and see where we go from there.
I'm not sure how many people will actually use JNIPort in Pharo or Squeak and need callbacks. Yes, I am interested, but given the small amount of time I have available for JNIPort, it may take some time until I can do something with your prototype. Also, JNIPort is currently just a hobby, and I will not use it in any kind of production software myself. I'm not sure if this qualifies as significant interest. ;-) Thanks! Joachim -- View this message in context: http://forum.world.st/Alien-and-callbacks-from-foreign-threads-tp3175989p317... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
JNIport is important for us. We should get a better interoperability with Java so that we can integrate instead of been rejected. Joachin your work is ***important***. Stef On Jan 5, 2011, at 7:54 PM, Joachim Geidel wrote:
Eliot Miranda-2 wrote:
That current version of Alien does /not/ support callbacks from foreign threads.
Aah, that explains a lot. ;-)
Eliot Miranda-2 wrote:
I have a prototype that does support callbacks from foreign threasds and supports non-blocking callouts on arbitrary threads. ... Are you interested in working with this prototype code? Pleaze let me know either way. I haven't sought permission to release this code yet but I would very much like to. I think there's value to Teleplace in my releasing it before we release it internally because it needs pounding on to bring up to production quality. If there's significant interest in this code I'll ask for permission to release it and see where we go from there.
I'm not sure how many people will actually use JNIPort in Pharo or Squeak and need callbacks. Yes, I am interested, but given the small amount of time I have available for JNIPort, it may take some time until I can do something with your prototype. Also, JNIPort is currently just a hobby, and I will not use it in any kind of production software myself. I'm not sure if this qualifies as significant interest. ;-)
Thanks! Joachim
-- View this message in context: http://forum.world.st/Alien-and-callbacks-from-foreign-threads-tp3175989p317... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
This is great news! Thanks a lot for your effort, Doru On 5 Jan 2011, at 18:22, Joachim Geidel wrote:
Hi everybody,
I am close to releasing JNIPort (http://jniport.wikispaces.com) for Pharo and Squeak. Almost everything works on both Mac OS X and Windows with one exception. I can attach a Java VM to Pharo/Squeak, I can send messages to Java objects and get results back, and even callbacks from Java to Smalltalk seem to work.
The exception is that a callback from Java to Smalltalk which comes from a different thread leads to a crash of the Squeak VM. I have not been able to figure out what the problem is. There is a similar problem with a hook of the Java VM: one can register a callback function which is called whenever the Java VM produces output for stdout/stderr. With Pharo 1.1.1 on Mac OS X, using this hook works when the hook contains a "nil halt", and if I simply proceed in each of the notifiers. When I remove the halt or replace it by a Delay, the image freezes. In Squeak 4.1 on Windows, the behavior is different: the VM crashes.
Does Alien support callbacks coming from a "foreign" thread? Or is this a limitation of Alien?
Thanks in advance for any help, Joachim Geidel
-- View this message in context: http://forum.world.st/Alien-and-callbacks-from-foreign-threads-tp3175989p317... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- www.tudorgirba.com "Being happy is a matter of choice."
participants (6)
-
Eliot Miranda -
Igor Stasenko -
Joachim Geidel -
Schwab,Wilhelm K -
Stéphane Ducasse -
Tudor Girba