I'm currently hacking httpd.pir a bit and came along the need for a
select/poll system interface (httpd.pir fails e.g. with konquerer, for
multiple connections).
We currently have:
1) PIO_unix_poll
It can select just on one fd, which isn't helpful at all (despite the comment
in the src code). Also the name is misleading, as it's implement using
select(2).
If we take 1), then the interface needs to be redone to take 3 arrays of PIO
PMCs or such. Passing in Boolean aka Bit arrays as fd_set might be
unportable.
2) The event system
It's not toatally ready to use it for waiting on file descriptors, but most is
already there.
A minimal interface could be:
event_add_IO_event(Interp, PMC* pio, PMC *sub, PMC *user_data, int which)
event_del_IO_event(Interp, PMC* pio, int which)
where which is _READ, _WRITE, or _ERR
If select returns with one of these pio fds, it would schedule an interpreter
IO event, which eventually runs the the user handler subroutine with:
.sub io_handler # the sub above
.param pmc pio # it got ready
.param pmc user_data
Solution 2) would be fully asynchronous.
Comments welcome,
leo
I've now (r14465) implemented almost all of the asynchronous select code and
it works nicely. There's an example too: examples/io/async_select.pir.
If folks think that we should keep this functionality [1], I'll cleanup a bit
(add function prototypes and symbolic constants) and complete the code.
[1] Instead of blocking on a select/poll system call, Parrot can do more
valuable stuff like garbage collection or running some GUI code.
Comments welcome,
leo