[Haskell-cafe] IO and exceptions
Alberto G. Corona
agocorona at gmail.com
Sun Nov 9 13:20:40 UTC 2014
This one:
https://hackage.haskell.org/package/control-monad-exception
2014-11-09 14:20 GMT+01:00 Alberto G. Corona <agocorona at gmail.com>:
> In the other side, this package does exactly what you want (I think).
>
>
> 2014-11-09 14:11 GMT+01:00 Roman Cheplyaka <roma at ro-che.info>:
>
>> Let's say you knew what exceptions could be thrown. What would you do
>> differently then?
>>
>> Typically, if it's a command-line app and something unexpected happens,
>> you simply present the error to the user. That's what exceptions do
>> already without any effort from you.
>>
>> If it's a server app, you catch exceptions at a certain point, log them,
>> maybe give some feedback to the client and proceed with the other
>> requests. In order to do that, you don't really need to know the set of
>> all possible exceptions.
>>
>> > `readChan` blocks the thread until it reads something. But what
>> > happens when channel is closed while one thread is blocked to read?
>>
>> What do you mean by "channel is closed"? Channels don't get closed;
>> there's no function to do that.
>>
>> It's possible that your blocked thread has the only remaining reference
>> to the channel; in that case, the deadlock may (or may not) be detected,
>> and an exception will be thrown in the former case.
>>
>> > Example to not being able to catch the exception:
>> >
>> http://hackage.haskell.org/package/network-2.6.0.2/docs/Network-Socket.html
>> > `recvFrom` blocks the thread until it reads something. However, what
>> > happens if socket is closed while `recvFrom` is blocking to read?
>> > Similar to `readChan`, we can't know this. What's worse is this:
>> > sockets have a `SO_RCVTIMEO` option, a timeout value for `recv_from`
>> > calls. What happens when we set that using `setSocketOption` in the
>> > same module and call `recvFrom` is unknown. This is really horrible,
>> > because a timeout exception is really something that you'd like to
>> > catch. Example: I have a thread that listens from a socket and handles
>> > some other events. I want to stop listening the socket after every
>> > second and handle events, then return listening the socket. But I
>> > can't know what it throws when timeout happens, so I have to catch all
>> > exceptions, which is horrible for a lot of reasons.
>>
>> It sounds like you're trying to write C-style in Haskell, which is
>> probably not the best way to do it.
>>
>> More Haskelly way would be to:
>>
>> 1. Use Network instead of Network.Socket and take advantage of GHC's IO
>> manager. That means that you'll be using something like epoll instead of
>> recvfrom under the hood.
>> 2. Instead of manually multiplexing several things into one thread
>> (listening on the socket and "handling some other events"), do that in
>> different threads.
>> 3. If you do need a timeout (not for multiplexing, but for a genuine
>> timeout), use System.Timeout.
>>
>>
>> Roman
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
>
> --
> Alberto.
>
--
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20141109/104cb0b7/attachment.html>
More information about the Haskell-Cafe
mailing list