Dan Sugalski wrote:
[snip]
> Here's what we *are* doing.
>
> We are going to do all I/O under the hood asynchronously. Completed
> async IO puts an event in the event queue.
>
> We are going to have a single unified event queue. All IO, timer,
> signal, and UI events go in it. All of 'em. We aren't going to do any
> of this "we have N different places to look for data" nonsense, where
> N is greater than three.
Don't forget, flock(), fcntl(), ioctl(), wait()/waitpid(), all the SysV
stuff, all the (get|set|end)(net|gr|pw)(ent|.id|name?) functions,
sendmsg, recvmsg, ... :)
I've occasionally wanted to do IO while waiting for an exclusive lock on
a filehandle, but I don't think it's possible without threads.
The closest you could come would be to intersperse the IO calls with
calls to flock(...,LOCK_EX|LOCK_NB). Sadly, this runs the risk of
"never" acquiring the lock, due to other processes always having it. If
you lock without the NB, then waiters will generally get the lock in
fifo order (well, it's at the whim of the OS, but most OSs try to
schedule unlocking in a way that avoid resource starvation).
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
