On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote: [It's worth considering making all the network I/O opcodes use a consistent way of marking errors. At the moment, all return an integer status code except for C<socket>, C<sockaddr>, and C<accept>.]
IIRC the Linux kernel uses negative values as return codes, where these values are the negation of the value errno would hold. If we can use simple numeric values to cover all possibilities, this seems like a good approach, as it avoids thread local issues with errno, and issues such as whether return values are in errno, h_errno, or returned by the call itself (C API for system calls, hostname lookups, threading calls respectively) So I'd suggest that the -1 in these two would be replaced: =item * C<recv> receives a message from a connected socket object into a string. It returns an integer indicating the status of the call, -1 if unsuccessful. =item * C<send> sends a message string to a connected socket object. It returns an integer indicating the status of the call, -1 if unsuccessful. As is, these are no different from print and read. The C socket API provides 3 functions, C<send>, C<sendto> and C<sendmsg>. C<send> is C<write> with flags. C<sendto> is C<send> plus an address to use. [Neither Stevens nor the FreeBSD man page say what happens if the address is given as NULL] C<sendmsg> is C<sendto> with the kitchen sink. We need a C<sendto> or better to do unconnected UDP sockets. If we make the address optional on our sendto-or-better then we don't need send. And given the frequency with which people write UDP socket code, I suspect that it would be better to provide ops only for C<sendmsg> and C<resvmsg>. =item * C<poll> polls a socket object for particular types of events (an integer flag) at a frequency set by seconds and microseconds (the final two integer arguments). It returns an integer indicating the status of the call, -1 if unsuccessful. [See the system documentation for C<poll> to see the constants for event types and return status.] poll should be available for all file descriptors, shouldn't it, not just sockets? Should the network opcodes even be loaded as standard? C<socket> et al aren't actually that useful on Perl 5 without all the constants in the Socket module, so in practical terms a redesigned Perl 5 would do better to remove all the socket specific keywords and make them functions exported by the Socket module. Should parrot go the same way? [And likewise System 5 IPC and shared memory builtins really should be functions, as should all the hosts/protocols/services/password lookups] Should the IO system provide symbolic lookup on AF_* and PF_* constants. IIRC at least one of these groups is OS dependant, as demonstrated by Solaris and SunOS differed on the values they used. It would be "useful" if this lookup could be flagged to happen in some way at bytecode load time. (Or maybe I want the moon on a stick alone with a "JIT this lazy constant" routine. Which probably does generalise, if functions can be marked as "cacheable" and the JIT can see a cacheable function taking only constants, and hence constant fold it) Nicholas Clark
