[MLton] OS.IO.poll problems
vesa.a.j.k at gmail.com
Sun Apr 1 05:13:07 PDT 2007
The OS.IO.poll function in MLton's Basis library is probably implemented
incorrectly. I say "probably", because the basis library specification
leaves a lot to be desired.
The specification says
returns the underlying poll descriptor from poll information pi.
I would assume that this means that you get a poll descriptor ("events"
flags) that is *equal to* the corresponding poll descriptor that you gave
to poll. In MLton's implementation this doesn't necessarily hold, because
the implementation derives a poll descriptor from the flags in the poll
information ("revents" flags).
Here is a simple example. Suppose we have (exactly one poll descriptor)
val pds = [OS.IO.pollIn (OS.IO.pollOut (OS.IO.pollDesc ioDesc))]
and then execute
val ids = OS.IO.poll (pds, NONE)
I would assume that
map OS.IO.infoToPollDesc ids = pds
but this doesn't necessarily hold in MLton. In MLton's implementation,
the left hand side may be equal to any one of
[OS.IO.pollIn (OS.IO.pollOut (OS.IO.pollDesc ioDesc))]
[OS.IO.pollIn (OS.IO.pollDesc ioDesc)]
[OS.IO.pollOut (OS.IO.pollDesc ioDesc)]
The last, perhaps surprising, case results from the possibility of
"revents" flags POLLERR, POLLHUP, and POLLNVAL, which may be set even if
the corresponding "events" flags aren't.
All in all, this means that even if the poll descriptor list given to poll
contained no duplicates, it may be impossible to associate the returned
poll information values to the poll descriptors that you gave to poll.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the MLton