[PEAK] Task containment and isolation
Phillip J. Eby
pje at telecommunity.com
Sun Jul 29 19:02:22 EDT 2007
At 10:20 PM 7/29/2007 +0000, Richard Tew wrote:
>It is possible to shift a tasklet created on one thread to another by
>pickling it and unpickling it on the target thread.
Ah. Well, that won't work with the current version of the Trellis,
which has what's effectively a thread-local variable. Once I switch
to using Contexual, it won't be a problem any more, because
Contextual *can* shift its State objects from one thread to another.
In the meantime, Trellis objects created in a given thread can only
be safely used from the thread where they're created, or Bad Things
Will Happen Silently. And not just the usual Threading Bad Things. :)
When I make the change to support Contextual, I'll also be changing
to support raising an exception when cells from one physical thread
or logical task attempt to access something belonging to another
physical thread or logical task.
Hm. It occurs to me that there won't be anything stopping code in
one thread that's *not* Trellis code from accessing cells that belong
to another thread, without making the checking process a bit more
complex. But I guess I could set an 'owner thread' attribute on
trellis controllers to handle that.
Hm... come to think of it, I could possibly make the trellis
*entirely* thread-safe by giving controller objects a lock that gets
acquired whenever non-trellis code tries to access a cell. That
might be worth thinking about, and it could probably be made
optional, so that by selecting what type of cell controller to use in
the context where you create the cells, you can decide whether you
want the cells to be accessible from another thread.
It won't help with inter-task or inter-thread communications, since
cells with different controllers can't safely interact. But it would
give us something very close to STM - software transactional
memory. The main thing that's lacking is an ability to roll back an
operation when there's an error... which I could probably implement
with care and a little logging, of both cells' old values and their
old dependencies, and perhaps some sort of general-purpose undo log
so that rules that store state or want reversible side-effects can
work. The logging would also slow things down a bit.
Still, it actually sounds pretty do-able, all things considered, and
the benefit of having fully transactional programs could be
enormous. Among other things, it means that if you have a number of
independent trellises (cell/component networks), you could spin them
off to any number of worker threads. In fact, that's pretty much the
definition of an application/transaction server: a bunch of trellised
applications with transaction input queues, fed by an I/O
system. worker threads pick up records describing transactions that
need doing, apply them to the right trellis, and send out the results.
More information about the PEAK