[email protected] said:
> On Tue, Mar 22, 2011 at 8:26 AM, Martin Sustrik <[email protected]> wrote:
> 
> > I would mimic UDP. I am open to suggestions though.
> 
> The recvmsg call is complex and not obviously a fit for 0MQ semantics,
> which are, IMO, either:
> 
> * get next frame and return that
> * get next multipart message and return that
> 
> In either case, reading into pre-allocated buffers is clumsy and I
> don't see how you can make it work since the caller cannot know the
> frame size ahead of time. The only suggestion I can make is to
> allocate frames on demand. If you try to fit the 0MQ recv into either
> UDP or TCP semantics, the result will IMO be weird and surprising in
> bad ways, so while you'll get a beautiful simple send(), no-one will
> use recv(), making this a useless exercise. People will end up doing
> insane things like writing their own frame headers so they can
> pre-allocate accurately.

See my reply to Martin. You can do it with standard recv() and return
EMSGSIZE if the supplied buffer is too small. Note that to be absolutely
clear such a recv() would operate on message parts, not entire messages,
i.e. just as zmq_recv() does now.

> > Btw, note that 0mq socket type can't be changed from void* to int. I wanted
> > to do that myself but then I realised that the file descriptor table is part
> > of the context rather than global and thus you would have to pass both
> > context pointer and int:
> >
> > zmq_send (context, sock, "A", 1, 0);
> 
> :-) Heh, it'll have to wait until (context == kernel).

Indeed, and this is the major reason why we (Martin and myself) care about
being as close to the API as possible. If we could get sockets as ints in
3.0 that would be wonderful; it means that with a future kernel
implementation you could just relink your application. But it does indeed
seem impossible to support sockets as ints and multiple contexts at the
same time.

-mato
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Reply via email to