[MLton] OS.IO.poll problems

Wesley W. Terpstra wesley at terpstra.ca
Tue Apr 3 03:25:16 PDT 2007


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.

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

This seems reasonable to me, too. On the other hand,

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

That's what I'd do if I was implementing something using OS.IO.Poll.

Unfortunately, that mechanism is pretty weak. The few times I've done  
networking with MLton I've had to rewrap the system 'kqueue' and  
'epoll' methods:
   svn+ssh://mlton.org/svnroot/mltonlib/trunk/ca/terpstra/st
I'll note that wrapping libevent
   http://en.wikipedia.org/wiki/Libevent
is might be a good idea if you need windows support.





More information about the MLton mailing list