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