Potential Network SIG
s.clover at gmail.com
Mon Aug 24 23:49:00 EDT 2009
The hardest part of network operations, I've found, is handling the
myriad of exceptional conditions safely, in such a way that there's
control over the number of sockets used and the timeouts in
connections (each step potentially needs its own timeout, in fact,
and one has to be careful with the interaction of asynchronous
exceptions here, or move to a different sort of model) while also
providing strong guarantees that resources won't leak. I.e. depending
on the stage of the connection process and type of exception,
different resources need to be freed.
network-fancy seems to be on the right track here, but I think
withSocket should absolutely take an optional timeout parameter (not
for the whole action, just for the connection). I'm also not too sure
that it won't leak as currently written -- i.e. if there's an error
in the connection loop itself, is the socket freed?
Of course something depending on the socket could still be returned
out of withSocket even after its underlying socket was closed. On the
other hand, if users really wanted guarantees, I think the signature
of withSocket is expressive enough that iteratees could be used
within the continuation it was passed. Lightweight monadic regions
would also be possible as an alternate API on top of this, as a
The server functions for network-fancy also seem pretty good.
Although it would be nice to have an MVar or other mechanism to shut
down the servers cleanly, rather than relying on asynchronous
exceptions, which might cause odd interactions. In particular,
listening on sockets can likely block exceptions, which means that if
you want to be able to shut down a server, you need to throw it an
exception, and then ping it to force the listen call to return.
Either we need some nonblocking way to listen, or that functionality
needs to be wrapped up in some neat abstraction.
Speaking of which, are we sure about what calls should be unsafe and
safe? The small price of marking things unsafe can lead to big
problems with blocking thread context switches, and thus grinding the
rest of an app to a halt. A key criteria for the network library, in
my opinion, should be that no network call on a given socket and
thread blocks any other work of the program, including another
network call on another socket and thread.
Additionally, while sockets are too nitty-gritty for a high-level
interface (although a socket with phantom types might not be),
Handles feel to me to be too tricky to reliably map onto, and I'd
much prefer something in between. Perhaps an explicit pair of a lazy
bytestring and a function of type (ByteString -> IO ()) (both, of
course, properly buffered.)?
Of course, this doesn't map onto some of the multicast and datagram
type functionality, which would need other abstractions.
On Aug 24, 2009, at 3:48 PM, Johan Tibell wrote:
> On Mon, Aug 24, 2009 at 8:00 PM, Bryan
> O'Sullivan<bos at serpentine.com> wrote:
>> On Fri, Aug 21, 2009 at 9:49 PM, Thomas DuBuisson
>> <thomas.dubuisson at gmail.com> wrote:
>>> 3) Use Bytestrings (and have corrosponding .Lazy modules) for
>> That's already a step up from the lowest-level bindings, which
>> should be
>> using Ptr a.
> My plan for network-bytestring has always been to offer a
> Network.Socket.Buffer with function such as 'recvInto' that work on
> buffers. The higher level bytestring interface can then be implemented
> in terms of this interface.
> I've been struggling a bit with how to expose less frequently used
> functionality in the BSD socket API such as the 'flags' parameter to
> 'send'. It feels a bit unfortunate to have to pass a "no flags" value
> in the most frequent case. Optional keyword parameters would be useful
>>> 4) Support more features
>>> Features such as Multicast, Header inclusion (IP_HDRINCL), address
>>> binding, etc. IOW, most the IP_ and SO_ options of socket (7)
>>> and ip
>>> (7) man pages. It would be rather nice if we were able to expose
>>> these in a friendly way - but with our cross platform concerns that
>>> might not be a good idea (e.g. I'm not familiar with windows).
>> Providing Network.Windows and Network.Linux and Network.BSD etc
>> would work fine for non-portable platform-specific features (of
>> which there
>> are many).
> I think this makes sense. I read some slides from a presentation on
> the next Java file API. The realization the Java community seemed to
> have come to is that you need to offer APIs with both a cross platform
> part and a platform specific part, preferably in such a way that both
> can coexist somewhat peacefully (i.e. not two completely separate
> class hierarchies).
> Libraries mailing list
> Libraries at haskell.org
More information about the Libraries