in reply to Re: Things you need to know before programming Perl ithreads
in thread Things you need to know before programming Perl ithreads
I think you can do these thing well with continuations. It would work like this. Instead of calling a blocking operation (like read or listen), you call the same in non-blocking mode and a yeald to the next thread repeatedly, until the non-blocking call succeeds. This can be implemented at any level: either Parrot could do it, or a threads library written in Parrot and using continuations, or your program.
For some operations it might be a problem that a non-blocking operation is unsupported by the OS. But there's an other problem unrelated with Perl: in some cases you cannot just use nonblocking syscalls, you need blocking calls (maybe in an other OS thread) to simulate a bckground operation. An example for this is opening a unix fifo. Opening either end of a fifo normally blocks until the other end gets opened. If both processed try to open a fifo with O_NONBLOCK repeatedly, the operation will never succeed (or only by chance after a long time, I don't know). Is this clear?
IMO, to solve this problem we'd need some kind of background system calls in the OS that can be started, then checked if it's finished nonblockingly, (or cancelled, or requested that a signal be sent when finished, but these are not quite important). We'd also need a new select syscall that can wait for multiple background syscalls. I would like an OS where all syscalls (except for the most trivial ones like getpid and time) can be started in any of these four modes: blocking, non-blocking, background, and signal-sending.
Some sub-cases are supported in linux too, but not a general mechanism I imagined here. For example, linux has read and write that runs in the background (asynchronous io), and can send signals when a filedes is ready for io, but this is not extended for other operations like opening a fifo.