schedule/runSchedule may execute actions out of order


The git history seems to claim that a scheduled action is supposed to be executed only after all earlier scheduled actions have been executed. The current implementation does not ensure this however. Note that multiple threads calling runScheduledAction can pull actions almost simultaneously from the channel and interleave their execution in any order.

Possible fixes are:
(1) Have a dedicated thread per remote endpoint (heavy-weight connection) executing scheduled actions.
(2) Have a runScheduledAction read an action from the channel and execute it atomically.

What is the need to execute actions in the order they are queued? The git comment is not clear about that. It says:

But the n-t interface does not ask to ensure ordering if messages are submitted concurrently.
The only problem I see is that sending messages could be attempted on a closed socket if they are submitted concurrently with a connection close call.




Alexander Vershilov
April 24, 2015, 7:23 AM

Threre are 3 kinds of actions that are scheduled:

  1. `sendOn`

  2. `sendOn >> trySocketClose`

  3. `trySocketClose`

Second - related two a response to remote endpoint when it announce connection close, so it seems out-of-order in this case will not harm.

sendOn uses MVar that protects writing to socket - so it serializes writes to socket, so they also could not happen out of order.

The problematic case could be scheduled `sendOn >> sendOn` action, in this case sends could be interleaved by another operation,
but it's not a case here.

In case if my analysis is not correct I have prepared a pessimistic patch that serializes actions being run:


Tim Watson


Facundo Dominguez



External issue ID




Affects versions