[MLton] OS.IO.poll problems

[Matthew Fluet]

Vesa Karvonen wrote:
> 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.

I generally agree with your analysis.  I don't understand the reason why 
the Basis Library only returns a subset of the input items, but given 
that it does, it does seem difficult to relate outputs directly to inputs.

> 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. 

One could also interpret this to mean that one gets a poll descriptor 
with the same bits enabled as the poll information.  Although, I must 
admit that your interpretation seems more natural.

 > 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).

Yup.  MLton's implementation was derived from that of SML/NJ, and their 
implementation still does the same.  Browsing through the PolyML 
implementation, it looks like it probably suffers from the same problem.

On the other hand, one can always use pollToIODesc and (pollToIODesc o 
infoToPollDesc) and use equality on the iodesc.

> 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.

Indeed, the last entry seems to violate the Basis Library specification, 
since it states: "a value in the returned list will reflect a (nonempty) 
subset of the conditions specified in corresponding argument 
descriptor".  On the other hand, OS.IO.poll is certainly meant to be a 
thin veneer over the poll system call, so it's not clear that much is 
gained by hiding the underlying behavior.  (That is, perhaps we should 
include isErr, isHup, and isNVal, possibly in a MLton.OS.IO structure.)

In any case, at the point of the poll system call, we have both the 
input poll_desc list and the output poll_info list, and we could easily 
modify the representation of poll_info to include the original poll_desc 
so that infoToPollDesc would have the behavior you describe.