Multiple threads processing connections#145
Conversation
There was a problem hiding this comment.
Ah - leftover code - wasn't meant to be pushed
There was a problem hiding this comment.
I think I have convinced myself, that this code does not have a resource leak in the exceptional cases, but it's really, really hard to get to that conclusion. I know it's asynchronous code, but is there any way to streamline the control flow?
There was a problem hiding this comment.
I'm sure there is - I'll file that as another issue in the interest of getting this PR merged.
There was a problem hiding this comment.
That's done in the callback below.
There was a problem hiding this comment.
I now see that dispose is already being called in the callback. Thanks @loudej
I leave this here as a reminder to call write2.Dispose() to avoid the closure allocation.
There was a problem hiding this comment.
I've verified that both pipeName's work on OS X. I think the logic where it defaults to "/tmp/..." for non-Windows OSs is good.
Will default to 1 until multi-loop stability is ensured
Multiple threads processing connections
Uses named pipes to dispatch connected sockets to multiple thread loops
Currently uses the number of processors from Environment to create threads. Should be a server setting in the future.