On Sun, Oct 17, 2010 at 5:55 PM, Damien Miller <d...@mindrot.org> wrote:
> On Sun, 17 Oct 2010, Marc Espie wrote:
...
>> What I'm talking about is mostly wrapping around recvmsg/sendmsg
>> and CMSG_DATA pack/unpack type routines.
>
> We had talked about putting fdpassing functions into libutil at one
> stage. IMO it would be better to go ahead with this and then wrap
> the result.
Right, 'cause if we had a design for that API, the perl API could be
modeled after it. Right now, I'm pondering the generic recvmsg() API,
which requires the caller to provide space for control data up front,
and thinking that something like:
($addr, $msg_flags, $control_data) = recvmsg($fh, $buffer,
$length, $flags, $control_len);
is the most basic level, but that's scary for a few reasons:
1) how do you, *in perl*, come up with the right value for $control_len?
2) so you parse $control_data with perl versions of the CMSG_* macros; can you
really map the numeric fds to perl filehandles *and have them close
correctly*?
3) unwary users that didn't handle SCM_RIGHTS would leak fds...though that's
really a bug in the UNIX API itself.
(Hmm, what does recvmsg() do with control data if MSG_PEEK is set?
Can you get fds twice by peeking at them? What happens if two fds are
sent but the receiver only provides room for one? Does the second
remain queued, does it get closed, or (hopefully not) does it get
lost?)
Philip Guenther
