Re: Re: Using objects and basic types from other Perl interpreters transparently.

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, to do that I think that I need to make a bidiretional communication between the RPO Server and the client. For now only the server wait's for inputs, and always send a response to the client, what make the execution of both sides synchronized. Or for now this can be done making the main thread/process as the server, and all the threads made from it, or any remote thread, will work as a client, since the real location of a shared variable is in the server side.

A bidiretional IPC will also enable a way to create a remote reference in the server side, let's say, a scalar in the server that points to a real scalar in the client. For now is only possible to make the oposite. And this will create something even more crazy, like have 2 clients, where the server points to a scalar in client 1, and the client 2 can get a reference to the remote scalar in the server, and when the client 2 access this reference it's actually accessing the client 1. So, is possible to create a network of remote objects without really know that!

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

Graciliano M. P.
"Creativity is the expression of the liberty".

Comment on Re: Re: Using objects and basic types from other Perl interpreters transparently. Download Code

Replies are listed 'Best First'.
Re: Re: Re: Using objects and basic types from other Perl interpreters transparently. by liz (Monsignor) on Apr 12, 2004 at 15:27 UTC
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	[reply] [d/l] [select]
Re: Re: Re: Re: Using objects and basic types from other Perl interpreters transparently. by gmpassos (Priest) on Apr 12, 2004 at 19:02 UTC
Is always nice to can count with other people! ;-P Since RPO is still in alpha stage, I have started it on saturday (2 days ago), I'm openned to change it's architecture. To make RPO a module that can be used by forks I need to add 2 things, a bidirecional IPC, and a driver, to can make the IPC with things different than socket, or plug it in other IPCs. I will be sending to you an e-mail talking about that things... Graciliano M. P. "Creativity is the expression of the liberty".	[reply]