Potential Network SIG

[Simon Marlow]

On 26/08/2009 16:43, Sterling Clover wrote:
>
>
> Simon Marlow-7 wrote:
>>
>> Could you elaborate a bit more on "Handles feel to me to be too tricky
>> to reliably map onto"?  I'd like to understand what problems there are,
>> and see if there's some way to address them.
>>
>
> I'm not a network/sockets expert by any means, but I've had to deal with
> doing some fiddly stuff in Haskell, and ended up just not trusting the
> Handle model, even though I know there's been some improvement and quite a
> few bugs have been fixed, etc. Additionally, these comments are based on
> what exists now in GHC 6.10.
>
> That said, my first gripe is that lots of operations on Handles are really
> only sane for actual files. Maybe these could be abstracted out, by
> parameterizing Handles over a phantom type, or by typeclassing? The file
> size operations are obviously meaningless, as are the get/set posn
> functions, and seeks, but hIsEOF and hLookAhead also seem problematic, not
> least because they force a buffer for even ostensibly unbuffered handles.

Ok, so is it fair to summarise this as saying you'd prefer there to be 
more static type safety to these operations, rather than the current 
dynamic type checking?  I couldn't agree more.

> Additionally, at least on windows, sometimes there is an IOError
> OtherException with error text "failed (No Error)" when an EOF should be
> provided. [That's really more a behavioural quirk/bug than a failing of
> Handles as such, I suppose]

That sounds like a bug, if you can reproduce it then please report it.

> As far as buffering goes, Handles currently couple buffering modes, which is
> potentially frustrating if one wants, e.g., no buffering on recv, but block
> buffering on send.

Buffering is always invisible on input - if there is any input 
available, you'll see it immediately.  It has performance implications 
only - but I can't imagine you'd want to deliberately reduce performance 
by turning off buffering (in fact, I think the new I/O library doesn't 
even honour NoBuffering on input Handles).

> Additionally, for many, though not all applications, it makes sense to
> separate the ability to close a handle from the ability to read or write to
> it, particularly for high-level, e.g., server APIs.

Yes - more detailed types would be nice.

> On the other hand, I'm less concerned with the ability to set options, since
> it seems to be that socket options can almost invariably be set as part of
> the initial connection/setup phase, and once you have a Handle or whatever,
> then the ability to change them isn't really necessary.

Still, we could provide a way to recover the Socket from a Handle if 
necessary (it would fail on a Handle that wasn't a Socket, of course).

The other question to consider is I/O multiplexing 
(select()/epoll()/etc.).  Right now if you use Handles with file 
descriptors you get this for free (not epoll() yet, but hopefully in the 
future).  If you do your own I/O, then you have to implement this too. 
Ideally the multiplexing of I/O should be available as a separate 
library that you can hook into from your own I/O code, and it would be 
used by Handles as well as from other libraries that need low-level I/O.

One other reason to want Handles: if you want to do something that 
involves changing encodings on the fly (e.g. reading an HTTP response) 
then Handles with hSetEncoding do the job nicely, the buffering and 
re-encoding is all handled behind the scenes for you.  This sort of 
thing would be tricky with bytestring and text.

Cheers,
	Simon