[PEAK] issues with Trellis event loops and threads

[Phillip J. Eby]

At 05:35 PM 7/21/2008 +0300, Sergey Schetinin wrote:
>Well, I get that, but I think that essentially, the only thing I need
>is to have the same Time instance be the current in more than one
>thread.

Well, your thinking is wrong, then.  :)

>  As long as that is true the newly created dependency in the
>non-eventloop thread will schedule a recalc in the main one. I realize
>that it depends on EventLoop implementation in use and that it might
>break with a future release, but I certainly think that in my case
>it's a lesser evil than isolating the threads cells completely. And
>the way Service and State are implemented I'm struggling to find a way
>to do that.

That's because you're not supposed to do that.  :)


>So if you could suggest a way to accomplish that,
>hopefully that's all I need. Also, if you have any ideas on how
>Trellis could handle multiple threads in the future (if there are any
>plans for that), that would be great to know.

The plan is for cells' ``manager`` attribute to be a lock object (one 
per thread), such that all the cells created by a given thread have a 
single shared lock.  This is sufficient to allow cells to be safely 
used and updated by multiple threads, including cross-thread calls to 
EventLoop and Time services.

To share those services across threads, you need to pass the active 
instances (EventLoop.get() and Time.get()) into the new thread, and 
then do something like:

      EventLoop <<= lambda: old_eventloop_service
      Time <<= lambda: old_time_service

Of course, none of this will actually work correctly at the moment, 
since cells don't have a manager by default.  You would have to 
install a specialized STM controller that uses a single global lock 
for all atomic operations.