This is an interesting problem, I think I might incorporate parts of it
into the next revision of my Concurrent Haskell tutorial.
It sounds like you're getting overwhelmed by several different problems,
and dealing with them separately would probably help. e.g. you want
some infrastructure
I'd say use of asynchronous exceptions should be a last resort. Developers
should be encouraged to explicitly model any event notification system they
use.
Regards,
Dave
On Tue, Jan 17, 2012 at 1:42 AM, Simon Marlow marlo...@gmail.com wrote:
This is an interesting problem, I think I might
On Tue, Jan 17, 2012 at 3:20 PM, David Barbour dmbarb...@gmail.com wrote:
I'd say use of asynchronous exceptions should be a last resort. ...
I agree. However, network libraries in Haskell (e.g. Handle,
Network.TLS) generally don't provide the primitives needed to do that
on the receiving end.
I uploaded a package that creates an STM layer over a network connection:
http://hackage.haskell.org/package/stm-channelize
I haven't used it in anger yet, but I hope it's a step in the right
direction. I included a sample chat client and server. The client is
pretty cute:
main =
I favor a wait-free concurrency model based on the `vat` from E language.
Vats can be modeled very easily in Haskell, and in many other languages. I
currently use such a vat model for my Haskell projects. I describe aspects
of it at a few places:
*
On Sat, Jan 14, 2012 at 1:29 AM, Bardur Arantsson s...@scientician.net wrote:
So, the API becomes something like:
runSocketServer :: ((Chan a, Chan b) - IO ()) - ... - IO ()
where the first parameter contains the client logic and A is the type of
the messages from the client and B is the
I've been trying to write networking code in Haskell too. I've also
come to the conclusion that channels are the way to go. However,
what's missing in the standard `Chan` type, which is essential for my
use-case, is the ability to do the equivalent of the unix select call.
My other slight qualm is
Disregard that last comment on `TChan`s; retry blocks. you learn a new
thing every day [=
Daniel
On 14 January 2012 11:27, Daniel Waterworth da.waterwo...@gmail.com wrote:
I've been trying to write networking code in Haskell too. I've also
come to the conclusion that channels are the way to
Hi guys,
I'm not happy with asynchronous I/O in Haskell. It's hard to reason
about, and doesn't compose well.
Async I/O *is* tricky if you're expecting threads to do their own
writes/reads directly to/from sockets. I find that using a
message-passing approach for communication makes
On 01/14/2012 11:42 AM, Joey Adams wrote:
On Sat, Jan 14, 2012 at 1:29 AM, Bardur Arantssons...@scientician.net wrote:
So, the API becomes something like:
runSocketServer :: ((Chan a, Chan b) - IO ()) - ... - IO ()
where the first parameter contains the client logic and A is the type
Hi Daniel,
I've been trying to write networking code in Haskell too. I've also
come to the conclusion that channels are the way to go.
isn't a tuple of input/output channels essentially the same as a stream
processor arrow? I found the example discussed in the arrow paper [1]
very
Hi Peter,
streamproc is a very interesting package, I'll surely use it somewhere
in the future. However, I'm not convinced that this solves my
immediate problem, but perhaps this is due to my inexperience with
arrows. My problem is:
I have a number of network connections and I have a system that
On 1/14/12 6:27 AM, Daniel Waterworth wrote:
p.s I'd avoid the TChan for networking code as reading from a TChan is
a busy operation. [1]
[1]
http://hackage.haskell.org/packages/archive/stm/2.2.0.1/doc/html/src/Control-Concurrent-STM-TChan.html#readTChan
The `retry`-ness will be rectified
I'm not happy with asynchronous I/O in Haskell. It's hard to reason
about, and doesn't compose well. At least in my code.
I'm currently trying to build a networking layer for my application
using Network.TLS. Here is a rather minimalist API:
newtype Connection = Connection (TLSCtx Handle)
On 01/14/2012 06:24 AM, Joey Adams wrote:
I'm not happy with asynchronous I/O in Haskell. It's hard to reason
about, and doesn't compose well. At least in my code.
[--snip--]
Async I/O *is* tricky if you're expecting threads to do their own
writes/reads directly to/from sockets. I find
15 matches
Mail list logo
