On Sun, Dec 2, 2012 at 2:59 PM, drush66 <davorin.rusevljan@gmail.com> wrote:

Would it be possible to start native thread inside pharo? This thread would run (for quite a long time) some event loop (like the libev), and post some info to the SharedQueue. Smalltalk code would in turn be reading stuff from this queue. You could say it would be pumping events from libev to SharedQueue instance for Smalltalk code to consume.

Is this doable? With NativeBoost or Plugin?

I have also found some info on threaded VM, but if I understand it correctly it seems more oriented to provide a thread to execute FFI call on it.

I wouldn't say that. The threading scheme is David Simmons' architecture, used in his AOS and S# VMs and similar to that used in the python VM, but more efficient. It allows multiple threads to share the VM, but only allows one to run Smalltalk at any one time. It is designed to allow Smalltalk to interact freely with any number of native threads. Cal-backs can come in from any thread. SMalltalk processes can be associated with specific threads, allowing one to control which thread a call-out is made on. -----

http://www.cloud208.com/ -- View this message in context: http://forum.world.st/using-a-long-running-native-thread-NativeBoost-or-Plug... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

-- best, Eliot

On 2 December 2012 23:59, drush66 <davorin.rusevljan@gmail.com> wrote:

Would it be possible to start native thread inside pharo? This thread would run (for quite a long time) some event loop (like the libev), and post some info to the SharedQueue. Smalltalk code would in turn be reading stuff from this queue. You could say it would be pumping events from libev to SharedQueue instance for Smalltalk code to consume.

Is this doable? With NativeBoost or Plugin?

I have also found some info on threaded VM, but if I understand it correctly it seems more oriented to provide a thread to execute FFI call on it.

I have a prototype for worker thread loop implemented in NB.. The idea is to call some function in that thread and then signal a semaphore when call complete. And of course making VM thread to be 'owned' by non-main thread needs to be supported. The main problem with this approach is that some primitives/functions has to be invoked in main thread.. and to control that, it will require some work in VM/language side to fulfill such requirement. The hard part of it, that we have barrier between language and VM, and lack of coordination to manage and correct usage of native threads. -- Best regards, Igor Stasenko.