Ptk and threading...redux..

FWIW: Yes I know that ptk doesn't support threads, and maybe never
will, but I think enough of us have produced sufficient experimental
results that the conversation isn't entirely closed...so forgive
me for thinking out loud here..

I've recently been working on solving some threading issues with
the DBI (see http://www.presicient.com/dbixthrd for current
status; apologies for pod2html's idiosyncrasies). As a result,
I've also recently developed a more robust thread queueing solution
(http://www.presicient.com/tqd), and have gained some insight into
possible solutions to the various issues raised by Perl's "heavyweight"
thread model (i.e., cloning the entire interpretter context).

DBIx::Threaded will (mostly) address the inability to share
DBI connection and statement objects between
threads by using an apartment threading model. For the unfamiliar,
the concept is heavily used by MSFT's COM architecture. In essence,
an object instance (or, in the case of DBI, object instance hierarchy)
is wrapped in its own thread, and all external communication occurs via
thin client proxies, usually over a thread-safe queue
(ala Thread::Queue::Duplex). Using this approach, I've managed to safely
and fairly transparently provide multiple threads access to a single
DBI statement object.

All of which got me thinking about finding a generalized solution
for apartment threading via either source filters and/or method
attributes. Alas, I've concluded the problem is probably too complex
for a generalized solution, but it did get me thinking about the
threads + ptk issues...hence, this missive.

I'm hoping to engender some thought and discussion about how
apartment threading might address the ptk threading issue.
Assuming the MainWindow and derived widget hierarchy were
encapsulated in an apartment thread, and client stubs created
to wrap the various widget objects, it seems feasible to
provide a reasonably thread friendly solution without much
(any?) modification to ptk itself, such that individual widgets
could communicate with any arbitrary thread. I envision
the most problematic areas would be

	1) event dispatch; since its initiated from the ptk apartment,
		a sortof "push" i/f is probably needed
	
	2) the numerous ptk i/f's that pass closures/coderefs as arguments;
		somewhat related to event dispatch. Client stubs would need
		to manage the coderefs, and the apartment thread would need
		to maintain a proxy for them.
	
	3) the sheer volume of widget classes: I'm not certain that every
		widget class would need some kind of wrapper; its possible
		that simple introspection/AUTOLOAD can be used to avoid touching
		any of those classes

I'd be interested in anyone's thoughts about the feasibility/desirability
of an implementation (Tk::Threaded ?), including any issues I may have
overlooked, and/or a sense of the scale of the effort (esp wrt item 3
above).

Regards,
Dean Arnold
Presicient Corp.
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ptk" to [email protected]