On Mar 6, 2006, at 4:06, Nicholas Clark wrote:
On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote:
=head2 Network I/O Opcodes
Functionality wise, the following are missing:
shutdown
Added.
getpeername/getsockname
getsockopt/setsockopt
These seem rare, and intimately associated with the I/O object
(they're just retrieving and setting attributes), enough to be left
as methods.
C<socketpair> isn't listed, but I'd assume that that is more a
class method
called on the class representing Unix Domain sockets.
Makes sense as a method.
Would it work to have classes representing each address format, each
providing a packsockaddr method?
I think it makes more sense to have a single opcode that returns the
appropriate kind of address object depending on the format of the
arguments you pass it. (Though internally it will rely on whatever
the chosen class uses to set its address information.) Though, a
single class that's smart enough to store different formats of
addresses may be better.
There's no direct access to fnctl or ioctl given. Specifically it
would be
useful to have a way to set handles non-blocking (and have the
entire IO
system cope with synchronous-but-non-blocking IO, even if async IO
is more
powerful still)
This is currently pioctl, but may be replaced by methods on the
ParrotIO PMCs.
Allison
