ZMQ sends and threads conflict

[GuillaumeMercier]

ZMQ doesn't seem to like threads (I saw some stuff about that in the documentation but can't find it right now).
Right now, all threads share the same context and thus uses the same socket to communicate with the server which
might be an issue. Or maybe ZMQ sockets don't like bursts of messages.
The error is the following:

[1,0]<stderr>: [quo-vadis error at (qvi-rmi.cc::qvi_zerr_msg::101)] zmq_msg_send() failed with errno=156384763 (Unknown error 156384763)
[1,0]<stderr>: [quo-vadis error at (qvi-rmi.cc::qvi_zerr_msg::101)] zmq_msg_send() truncated with errno=156384763 (Unknown error 156384763)

Adding some delay in the example (with a call to sleep) fixes the issues, adding a lock doesn't fix anything so I will investigtate the burst of messages. I already tried option for ZMQ sockets but without positive results.

See PR #163

[samuelkgutierrez]

I'll take a look, @GuillaumeMercier. Thank you.

[samuelkgutierrez]

I have a fix doing it a brute-force way, but let me see if I can come up with a nicer solution.

[GuillaumeMercier]

And what is the current fix? I'm curious.

[samuelkgutierrez]

Having a context mutex managed by a lock_guard at the interface boundary. A little heavy handed, so I think I can do better.

[GuillaumeMercier]

But I think I tried this and it didn't work.

[samuelkgutierrez]

I'm not sure how you implemented it, but mine seems to do the trick.

[GuillaumeMercier]

struct qv_context_s {
    qvi_rmi_client_t *rmi = nullptr;
    qvi_zgroup_t *zgroup = nullptr;
    qvi_bind_stack_t *bind_stack = nullptr;
    pthread_mutex_t lock;

[GuillaumeMercier]

Ok, I'm puzzled.

[GuillaumeMercier]

I guess it has to do with when/where you do lock/unlock

[GuillaumeMercier]

I put the lock/unlock phase around the call to qv_bind_push in qv_thread_routine

[samuelkgutierrez]

@GuillaumeMercier your issues should be fix by #164. I've also pushed a new branch named thread-bug-work that has the fixes to build your code. When you are ready, please issue a pull request so I can merge your work into master.

[samuelkgutierrez]

@GuillaumeMercier things look much better now since merging #189. For what it's worth, there were other issues outside the RMI and threading impacting this one (e.g., unreliable binding after split). One particularly nasty bug to track was stale task data being passed to hwloc. Now these data are gathered at the time the call is performed. And the relevant task details update appropriately when threads are introduced. Closing for now, but please re-open if needed.

[GuillaumeMercier]

@samuelkgutierrez : so, did you get rid of the lock?

[GuillaumeMercier]

I'll update my repo and make tests asap.

[samuelkgutierrez]

Yes, I got rid of the lock. Let me push a minor update before you test.

[GuillaumeMercier]

No sweat, I won't make tests today, but maybe tomorrow.

[samuelkgutierrez]

The minor change is in. Thank you for testing! Fingers crossed.