About adding the resource, what you mean with

my $thread = threads->remote( "host:port" );
[download]

this is a thread that exists in other interpreter?

Well, it would look like a thread to the local program. It's just that the thread runs somewhere else.

Actually, you would need it to tell what sub to run on the other side as well, so I guess the syntax would be:

my $thread = threads->remote( 'host:port:namespace::subname' );
[download]

and consequently, forks should have a seperately installable server functionality as well (which now only happens in a fork).

Currently, when you register a shared variable, it is the server who assigns ordinal numbers to know which variable is associated with what remote variable. Currently the numbers are the same on either side, so some type of mapping would be needed. And other things would prop up as well. But if we could get this together, then not only could you offload threads to other systems, you would have create a very transparent Perl RPC mechanism as well.

But you already have some bidiretional socket system for forks, not? Maybe I can use it.

forks uses the blocking behaviour of sockets to handle all the locking and cond_wait/signal/broadcast issues. So all of your locking issues should be handle by that already. So yes, I think you can definitely use the code, or even better: integrate it into forks.pm.

I'm willing to work with you on that!

Liz