30.03.2011, 12:12, "Martin Sustrik" <[email protected]>: > Can you spell out more clearly what's the problem > with zmq_content_t?)
The only problem is another memory allocation. If I want to use another memory allocation technique for performance reasons, allocation of content_t structure can make all the benefits negligible. Probably API for it can be introduced, like zmq_msg_metadata_size(), to get size of metadata structure, and zmq_msg_init_metadata() which would accept a data pointer prefixed with data size. Not sure if this complication is worth it in practice, though. > > As for the recv() side, there's no way at the moment to specify what > allocation mechanism should be used. > > You are right that it should be done on socket level (setting alloc/free > function pointers using setsockopt, for example). Great news! And thanks for good explanation. BTW, if we discussing features for 3.0. I'd like to propose few things. 1. Have you considered implementing devices inside the IO thread? I'm sure it's controversal, but there are lots of cases where devices are unavoidable, but adding a tens of context switches for each message affects performance very negatively (we have a recv call on each zmq_recv and each zmq_send of single message part). 2. Currently there is no way to close PUSH/PULL or PUB/SUB socket or even probably a REQ/REP socket without loosing a message. The only combination that works is XREP/XREQ (and XREP/XREP), and this while doing all the bookkeeping yourself. I know that it's intentionally, because by design my system needs to be failure resistant and so on. But there are lots of use cases which needs that. E.g I want a local process start, process single message and die peacefully. Today, I'll loose more messages than process. Second use case, is if I have a device which load balances messages between local processes by ipc://. I know that the only reason for processes to disconnect is when I want to restart process to get software update (crashes are quite rare). Okay, it's even more controversal example. I have client which will repeat request if there is a network trouble for sure. But restart is going to loose at least tens of messages and timeout is for very hard edge cases, because of latency. And really what's the purpose of message queue, which can't queue messages for me? :) -- Paul _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
