1) Async vs sync
Currently the ParrotIOLayerAPI [1] has distinct entries for Open, Read, Write with _Async appended. These are of course all unimplemented. Dan's draft [2] has additionally async variants of seek and tell [3].
I'm thinking of a separate IO layer (above the default OS layer(s)) that implements Read, Write, ... as async oerations. The passed function arguments (or a flag) can indicate, if actually an async or a sync IO operation should be done.
Further: for miniparrot we need a fallback of the async IO ops, so that an async IO emulation layer can be pushed above the stdio layer that emulates the async IO API.
2) Send vs Write, Recv vs Read
The socket read and write functions are currently also special entries in the API vtable. Using these distinct entries from opcodes would need that the compiler has knowledge, if a C<print> function goes to a file or to a socket. I think this isn't possible [4].
So, again, I think these socket functions should be implemented in a separate IO layer. The ParrotIO structure has inside C<flags> a bit, if the ParrotIO refers to a socket. The layer can pass on the request to the next layer, if it can handle the request because the socket bit doesn't match.
It's of course debatable if Open() really fits into a socket layer scheme or if it should be a distinct function entry Socket(). But I can imagine that somehing like:
open P0, "http://some.cc:80";
does the right thing.
3) Fill and GetCount
What are these functions slots for?
Comments & answers welcome, leo
[1] basically a vtable of functions per IO layer
[2] Subject: First draft, IO & event design
[3] the AIO docs in "info libc" indicate that after issueing an aio_read or aio_write, the file position is undefined, because these functions might execute in any order. The async tell or seek seems really to be needed, if one async read depends on the previous async read and the amount of data isn't known yet (e.g. tail -f the_log_file)
[4] e.g. perldoc perlipc, the socketpair example
