Open GuillaumeMercier opened 1 month ago
I'll take a look, @GuillaumeMercier. Thank you.
I have a fix doing it a brute-force way, but let me see if I can come up with a nicer solution.
And what is the current fix? I'm curious.
Having a context mutex managed by a lock_guard
at the interface boundary. A little heavy handed, so I think I can do better.
But I think I tried this and it didn't work.
I'm not sure how you implemented it, but mine seems to do the trick.
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;
Ok, I'm puzzled.
I guess it has to do with when/where you do lock/unlock
I put the lock/unlock phase around the call to qv_bind_push
in qv_thread_routine
@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.
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:
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 https://github.com/hpc/quo-vadis/pull/163