- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Alien and callbacks from "foreign" threads?

by Tudor Girba

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-tp3175989p31… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- www.tudorgirba.com "Being happy is a matter of choice."

Jan. 5, 2011

Re: [Pharo-project] Alien and callbacks from "foreign" threads?

by Joachim Geidel

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-tp3175989p31… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 5, 2011

Re: [Pharo-project] Alien and callbacks from "foreign" threads?

by Eliot Miranda

On Wed, Jan 5, 2011 at 10:36 AM, Igor Stasenko <siguctua(a)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. > >

Jan. 5, 2011

Re: [Pharo-project] Alien and callbacks from "foreign" threads?

by Joachim Geidel

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-tp3175989p31… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 5, 2011

Re: [Pharo-project] Alien and callbacks from "foreign" threads?

by Igor Stasenko

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.

Jan. 5, 2011

Re: [Pharo-project] Alien and callbacks from "foreign" threads?

by Eliot Miranda

Hi Joachim, On Wed, Jan 5, 2011 at 9:22 AM, Joachim Geidel <joachim.geidel(a)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-tp3175989p31… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Jan. 5, 2011

Re: [Pharo-project] Alien and callbacks from "foreign" threads?

by Schwab,Wilhelm K

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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Joachim Geidel [joachim.geidel(a)onlinehome.de] Sent: Wednesday, January 05, 2011 12:22 PM To: pharo-project(a)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-tp3175989p31… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 5, 2011

[Pharo-project] Alien and callbacks from "foreign" threads?

by Joachim Geidel

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-tp3175989p31… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 5, 2011

Re: [Pharo-project] Best way for change a window style

by nullPointer

CLFramework continues in develop but donÂ´t the subset UIBuilder. For the change of window styles I didnÂ´t almost update UIBuilder. Regards. -- View this message in context: http://forum.world.st/Best-way-for-change-a-window-style-tp3032341p3175983.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 5, 2011

Re: [Pharo-project] Fwd: [Pharo-users] Smalltalk server pages

by Sven Van Caekenberghe

On 05 Jan 2011, at 16:34, CÃ©drick BÃ©ler wrote: > Otherwise, I would look at ZnHTTP instead of Kom at least for HTTP Server. You could also have a look at Iliad or Aida which I think are less memory hungry than seaside (but to me, nothing beats pure html anyway with a fake dynamic impression ;) ). If you only need to build a couple of very simple HTML pages (say like for some embedded device) you could use Zn. It is very lightweight, both in the number of classes and in its dependencies. However, Seaside offers an enormeous amount of functionality that you will miss. You will have to generate HTML by hand for example. Sven

Jan. 5, 2011