RFC: AnyEvent::Handle with two non-duplex filehandles
Mark Lawrence
nomad at null.net
Tue Apr 23 05:09:57 CEST 2013
On Mon Apr 22, 2013 at 11:10:27AM +0200, Marc Lehmann wrote:
>
> create a socketpair, fork, dup it over stdin and stdout, exec ssh and
> you are done. no need for fancy modules either.
Ok, until now all I had considered was pipe-based communication. Thanks
for the tip.
> I didn't know open returned or required two handles, how do you do
> that?
I didn't quite mean it that way. What I meant was it either allows for
reading, or writing, but not both together.
> > IPC::* etc) all seem to return or require separate in/out
>
> Are you sure they require separate handles? That happens when you
> pass in the same handle for stdin and stdout?
Given that they are mostly pipe based (one-directional at least on
Linux) I would expect this to fail, but I haven't confirmed this.
> > $state = calculate_state(); $whl->push_write(...);
> >
> > $rdl->push_read(line => sub { $state = calculate_state_again();
> >
> > # handle the read, and then push another write...
> > $whl->push_write(...); $rdl->push_read(...); });
>
> <....>
>
> The easy solution that should alwas work is have a wrapper object
> that only points to the real object(s) - since nothing inside keeps a
> reference to the wrapper, it's DESTROY can unravel the object
> hierarchy. XML::Parser uses this for example.
Do you mean something like this?:
my $wrapper;
$wrapper = bless {
handle => AnyEvent::Handle->new(
on_read => sub {
my $hdl = shift;
# access other things with $wrapper->{other}
},
),
other => $thing,
},
'MyWrapper';
However as I see it, I have still created a ref-count issue of some
kind here: $wrapper contains a reference to itself inside the subref,
no?
Ideally perhaps I would make an AnyEvent::Handle object the wrapper,
and add other things to _it_? Then there is no need for variables to be
scoped inside anonymous subrefs:
my $handle => AnyEvent::Handle->new(
other => $thing,
on_read => sub {
my $hdl = shift;
# access other things with $hdl->{other}
},
);
--
Mark Lawrence
More information about the anyevent
mailing list