[zeromq-dev] Common Lisp pzmq recv-string on inproc blocks other threads

[Alexander Pugachev]

Hi,

I am using ZeroMQ 3 with Common Lisp library pzmq. I am trying to send a
message to server part of inproc PAIR in the main thread from client side
of PAIR in a thread derived from main. It looks like recv-string operation
blocks both threads at the same time while poll does not.

recv-string basically call msg-init, then calls msg-recv until ZMQ_RCVMORE
is returned by getsockopt(). It's ok that it blocks, I just do not
understand why it blocks other thread.

This code

(defun a(endpoint)
>   (pzmq:with-socket socket :pair
>     (log:info "in thread")
>     (pzmq:connect socket endpoint)
>     (log:info "connected")
>     (pzmq:send socket "test")
>     (log:info "sent")))
> (defun simple-inproc-test()
>   (let ((endpoint "inproc://s"))
>       (pzmq:with-socket socket :pair
> (pzmq:bind socket endpoint)
> (log:info "bound")
> (bt:make-thread (lambda () (a  endpoint))
> :name "the-thread")
> (log:info "before recv-string")
> (log:info (pzmq:recv-string socket))
> (log:info "after recv-string!")))))


logs only

<INFO> [02:13:51] hi tmp.Osy6Ca (simple-inproc-test) - bound
>  <INFO> [02:13:51] hi tmp.Osy6Ca (simple-inproc-test) - before recv-string


and when I terminate main thread (running function simple-inproc-test) I
see "<INFO> [02:13:54] hi tmp.CTSEWq (a) - in thread"  and then obciously
child thread dies when it tries to send a message in the socket without
running server side.

If I replace the recv-string line with polling loop returning on first
occurence of POLLIN in the socket I successfully receive the message:

      (pzmq:with-poll-items items (socket)
> (loop
>    (pzmq:poll items)
>    (when (member :pollin (pzmq:revents items 0))
>      (log:info (pzmq:recv-string socket))
>      (return))))




I was trying to play with parameters of context, sockets and was trying to
create sockets in different contexts and in the same context passed to new
thread function - it is all the same, and now I think this is some ZeroMQ
principle I haven't read or understood.

Am I doing something completely wrong? How blocking receive operation in
one thread can block other thread as well?

Thanks, Alexander.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130923/e661f117/attachment.htm>