[MLton] OS.IO.poll problems

[Matthew Fluet]

Wesley W. Terpstra wrote:
> On Apr 2, 2007, at 4:50 PM, Matthew Fluet wrote:
>> 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.
> 
> There is a good reason for this. Imagine you have a TCP socket. You're 
> interested in receiving new requests (say HTTP requests) from the 
> socket, so you want to mark the socket as interesting for reading. 
> However, you are also still servicing the last request by reading a file 
> from disk and writing it to the socket whenever the socket's write 
> buffer has space. Thus, you are also interested in writing to the 
> socket. (This is a real world example for servers supporting HTTP 
> pipelining)
> 
> Therefore, you'll want to watch the socket for both read and write 
> events. However, when one of those events happens, you need to know 
> which happened. I wouldn't want poll to tell me 'the socket is either 
> readable or writeable'. I want the subset of my watch conditions that 
> was met. Then I can decide which actions to take.

That's a fine example; however, I was speaking about the fact that the 
list of poll_info values returned by 'poll' may be shorter than the list 
of poll_desc values submitted to 'poll'.  Hence, you get results 
corresponding to a 'subset' of the inputs; for each result, you also get 
a 'subset' of the watched conditions.

My point was simply that if 'poll' returned a list of the same length as 
the input (with each result having exactly those conditions (including 
no conditions) that were met set), then one could exploit the fact that 
the nth output item corresponded to the nth input item.  It would also 
more closely match the underlying C-call, which gives a result for every 
input.