[zeromq-dev] .NET port

[Martin Sustrik]

On 08/07/2011 02:34 PM, Fil Mackay wrote:

> How stable is 3.0 - lots of bugs, not production ready? My inclination
> is to go for 3.0... onward and upwards and all that.

No bugs have been reported so far IIRC. That may be caused either by 
stability of the codebase or a modest amount of those who already 
migrated to 3.0.

> OK I know how IOCP works - can you explain how the POSIX equivalent
> (what's it called?) works, so I can understand the difference between
> the two? Does it use any asynchronous actions, ie. notify me on data
> arrival, or is everything blocking on some kind of recv() call? What are
> the central classes that will be impacted in implementing IOCP?

POSIX polling works the same way as 0MQ's zmq_poll() function. You poll 
on a socket, asking for either write access (POLLOUT) or read access 
(POLLIN). If at least one byte can be written or one byte can be read, 
polling function exits and notifies you about the fact. You can 
read/write data afterwards as needed.

See for example documentation for select() function:

http://pubs.opengroup.org/onlinepubs/009695399/functions/poll.html

One thing I don't understand about IOCP is how it notifies the user that 
TCP transmit buffer is full and more data can be sent and how it later 
notifies you that there's free space in the buffer and you can send more 
data...

> Is the intention that IOCP would be used for client and server comms?
> Normally on Windows you only use IOCP for high-performance server
> scenarios where you want to break the 1-connection-per-thread limit.

That's how 0MQ works. There are I/O threads, each handling arbitrary 
number of connections.

> Why are named pipes so much different/more difficult than TCP?

Named pipe is represented by HANDLE, not a SOCKET. select() function 
works only with SOCKETs. To handle HANDLEs, you need to use IOCP.

> Named pipes would be pretty heavyweight/slow for shared memory
> notification, I'd be looking at either (a) spinning on volatile variable
> for low-latency scenarios, or (b) ManualResetEvent otherwise.

Sure. However, you have to find a way to poll on multiple such 
synchronisation objects. So, presumably, the latter rather than the former.

> So, pipe_t (I'm learning the zmq lingo) is a single writer, many reader
> queue?

It's single writer, single reader queue.

Martin