[PEAK] issues with Trellis event loops and threads

Phillip J. Eby pje at telecommunity.com
Tue Jul 22 13:38:21 EDT 2008


At 07:27 PM 7/22/2008 +0300, Sergey Schetinin wrote:
>So this seems to work. Any hints about what to look out for?

Make sure that your thread *never* accesses any methods of shared 
services except inside trellis rules, or if it explicitly holds your 
global lock.  Those methods (such as Time.reached(), which is called 
by bool(aTimer)) may access private attributes that are not cells and 
thus not protected by your global lock.


>Also, I think I found a bug with the basic EventLoop implementation --
>the main loop never exits if there were any events scheduled,

That is correct and intended behavior.  You are meant to explicitly 
terminate event loops; it's an extra feature of the basic EventLoop 
that it automatically exits when nothing is queued or scheduled.


> > Bear in mind, however, that doing this is an incredibly, horrifically bad
> > idea  and you should never actually do it, because most services aren't
> > going to be sharable across threads.  Really, you should explicitly share
> > those services that need to be -- and CAN be -- shared across threads.
>
>Well, the reason to use Contextual for me (apart from Trellis) is that
>because the code that performs some actions doesn't know about all the
>context that is required for the underlying operations (as there are
>multiple backends), with Contextual it's possible, in a way, to pass
>the parameters to code that will only be called some levels deeper
>into the stack, and sometimes the call can happen in another thread.
>Is that a misuse of the library or should I be safe as long as I only
>use my own services in this way?

It's not a misuse of the library; but the idea is that most of the 
time you'll share service *factories* across threads, not service 
*instances*, unless the service is in fact thread-safe.

Contextual is still in fairly early development, though.  A later 
version will offer a way for service factories to depend on the 
thread in which they're run, which will automatically ensure that 
instances don't get shared across threads.  (Really, this should be 
Contextual's default behavior, with a way to override it to specify 
that a service is supposed to be threadsafe.)




More information about the PEAK mailing list