Good news Pieter, finally, CURVE works even when I penalise the
handcheck, whatever implementation I use (multithread or sub-processes,
shared context or not). Here is the report of my experiments (the first
two was already described in the previous messages):
1. Client multithreading with one shared context and the control socket
with an inproc transport : works
2. Client multithreading with one shared context and the control socket
with an inproc transport, when 2ms or 20 ms delay is introduced
inside
zmq::curve_(client)|(server)_t::(next_handshake)|(process_handshake)_command
: works (warning : needs increase of time at msleep (20000);
3. Client multithreading with one context per client thread and the
control socket with a TCP transport (mandatory since inproc works
only in the same context) <http://pastebin.com/iVum5aGx>: works with
2ms delay, and even with 20 ms delay (but needs increase of time at
msleep (5000); line 281)
4. Clients as sub-process <http://pastebin.com/wCs2s18G> (fork): works
with 20ms delay
WARNING: my only GO/NOGO criteria is the number of DTOR in both clients
and server. It is a very weak criteria but enabled me to have an easy
way to investigate. I may come back with a full test when I have time.
The problem was I stopped the threads or the sub-processes from main
before the work was performed. Penalizing each step of the handcheck
makes things far longer :-[ !
The positive point is that we have now a set of examples.
Cheers,
Laurent.
Le 29/10/2013 15:09, Laurent Alebarde a écrit :
Hi Pieter,
Could this be the source of my problems ?
/One of the big architectural blunders I've done in ZeroMQ is its
threading model. Each individual object is managed exclusively by a
single thread. That works well for async objects handled by worker
threads, however, it becomes a trouble for objects managed by user
threads./ <http://www.freelists.org/post/nanomsg/nanomsg-01alpha-released>
Or has it been fixed ? May I expect it would work if I fork the
clients instead of using threads ?
Cheers,
Laurent
Le 28/10/2013 16:30, Laurent Alebarde a écrit :
Thanks anyway Pieter. I found a description
<http://zeromq.org/whitepapers:architecture> of the internals of
libzmq 2, but nothing about timeouts. Thought, when I run
test_concurrency_curve.cpp <http://pastebin.com/3xUbWEPj> with 2 ms
delays into :
* zmq::curve_client_t::next_handshake_command
* zmq::curve_client_t::process_handshake_command
* zmq::curve_server_t::next_handshake_command
* zmq::curve_server_t::process_handshake_command
it stops working correctly (1 ms works well). I have not investigated
the causes (just used DTOR traces), but I think it is expected to
work ? Otherwise, the library may fail to work properly in some
exceptional cases (may be concurrent running of more proprietary big
processes), or in my case more cpu consumming mechanisms would fail.
What do you think of that ? Should it be fixed ?
Le 25/10/2013 17:29, Pieter Hintjens a écrit :
Laurent, I'm sorry, I don't know the internals of how mechanisms
handle timeouts.
On Fri, Oct 25, 2013 at 5:25 PM, Laurent Alebarde<l.aleba...@free.fr> wrote:
The problem exists even in a normal run. Investigating without a debugger is
very difficult.
What are the "timeouts" available in libzmq internals I can play with ?
I have one point to examine: in my trace, I have indented depending on the
client id, and some printf are not in the good columns. That may be a good
start I assume ?
Le 25/10/2013 17:17, Pieter Hintjens a écrit :
On Fri, Oct 25, 2013 at 4:22 PM, Laurent Alebarde<l.aleba...@free.fr>
wrote:
My question is:
Considering CURVE, Is there some time delay I should deactivate when some
threads are paused ?
Are you still using a debugger? That is always going to make things
work bizarrely.
You should use whatever timeout seems reasonable, and tune it if you
find problems with your first choice.
-Pieter
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
