[MLton] OS.IO.poll problems

[Vesa Karvonen]

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

 infoToPollDesc pi
    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)]
  [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.

-Vesa Karvonen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton/attachments/20070401/2831714c/attachment.htm