On Mar 5, 2006, at 15:35, chromatic wrote:
On Sunday 05 March 2006 11:46, Nicholas Clark wrote:
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)
Parrot, not being C, does have exceptions....
That was my thought. It partly depends on how people will be using
it. For asynchronous I/O, exceptions actually make more sense than
integer error codes.
It would be a pain to maintain two separate sets of opcodes, one with
integer error codes and one with exceptions. So, to figure out if
it's feasible to switch entirely over to exceptions, we need a
"story" for building the system based on exceptions and emulating
integer error codes for the HLLs that use them. Perhaps the HLL
implementation can trap certain exceptions, retrieve the error code
from the exception itself and return that. Or, if that's too much to
put on the shoulders of compiler implementers, perhaps we provide a
layer of opcodes that trap the I/O exceptions and return integer
error codes instead.
Allison
