[PEAK] Task containment and isolation

[Phillip J. Eby]

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.