Login  Register

Re: Alien and callbacks from "foreign" threads?

Posted by Stéphane Ducasse on Jan 05, 2011; 10:21pm
URL: https://forum.world.st/Alien-and-callbacks-from-foreign-threads-tp3175989p3176558.html

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 <[hidden email]> 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.
>
>