The code I used was (sorry if this doesn’t get formatted correctly):

module Main
    where

import Control.Concurrent.Chan
import Control.Concurrent.Chan.Split

main = main1

payload :: [Integer]
payload = [1000000000000000.. 1000000010000000]

-- test traditional Chan implementation:
main0 = do
    putStrLn "Starting to write"
    s <- newChan
    mapM_ (writeChan s) payload
    putStrLn "Done"

main1 = do
    putStrLn "Starting to write"
    s <- newSendPort
    mapM_ (send s) payload
    putStrLn "Done"

No, I haven’t benchmarked. I find that surprising, but only a little bit. (I’m not surprised by being surprised at GHC optimizations.) It’s probably better to not rely on this particular optimization though, unless it’s a particularly well-understood and reliable optimization. I would expect it to be relatively easy to come up with use cases where the optimization doesn’t kick in, for reasons that may be less than immediately obvious.

I’m very interested in seeing your benchmark, though.

I certainly see the benefit to making it easier for the GC to do its duties, but I’m wondering if there are any cases where you’ve seen your implementation have better behavior then straight Chan with optimizations on.

Regarding listen and race conditions, I don’t think it’s going to be especially problematic compared to any other concurrent operator. I would reemphasize that listen is the equivalent of dupChan, so you can create the exact same problems as you can with Chan. And I think it enhances the potential advantage of having zero ReceivePorts, otherwise this situation is a lot less useful, in my opinion. I mean, the program that initially motivated this library required the use of listen.

I would point out that that the “zero receive ports” is something of a special situation, that the real advantage is the finer-grained types. I’ve only found one use for that situation, which is my fork of the pgsql-simple library, and that code was only in production for a couple of months before being replaced with the postgresql-simple library. And even then, the motivation was providing pgsql-simple with some desirable properties; the client of that library didn’t actually make use of those particular properties.

If not for the fact that I really like having SendPorts seperate from ReceivePorts, I probably wouldn’t still be using this library in other projects, and probably wouldn’t have released it on hackage.

A couple questions: doesn’t the existence of ‘listen’ weaken your advantage no. 1, since we can always get a receive port from a SendPort? won’t it be difficult to use ‘listen’ effectively (i.e. without throwing messages “into the aether” non-deterministically) in real concurrent code?

The problem is that a Chan is basically a pair consisting of a SendPort and ReceivePort, so an active channel necessarily has a reference to at least one ReceivePort. Thus messages will build up in that channel if somebody is talking and nobody is listening. So I got rid of that pair and made a few other small improvements.

You can take a look at the github repo if you are impatient.