[zeromq-dev] Rewriting zeromq internal thread management

Kenneth Adam Miller kennethadammiller at gmail.com
Fri Jan 10 23:43:21 CET 2014

I need to undertake the fastest possible route to force zeromq's internal
thread management to spawn threads in another fashion.

[minor background information needed]
Intel Pin is a dynamic binary instrumentation framework. It basically
allows developers to define callbacks at different granularity levels; at
every instruction/image load/function execution/function return/signal
reception (you name it). So basically you give your pintool a target
process, and the PIN runtime executes that target process while weaving
your callback routines so that they get executed based on where you specify
with you instrumentation routines.

I would really like to make use of ZeroMQ within a pintool because
currently Intel's PIN tool doesn't have much inter thread communication
facilities, or good networking facilities beyond what the programmer
writes. The problem stems from the the fact that PIN instruments all
threads spawned by the standard library and interposes its own library that
you can use to spawn threads in order to maintain segregation between the
threads that are loaded between the target process and the instrumentation
routines that you define.

PIN does provide it's own method to spawn a thread;
PIN_SpawnInternalThread, and it accepts thread function pointer, some
arguments and a stack size and location where the function can place the
threadID of the new thread it created. Using something like this, do you
think it would be possible to simply write a drop in replacement by
abstracting the thread creation function in a wrapper and simply compiling
zeromq to either use or not use the PIN API? Also, if this approach isn't
so easy, how difficult would a rewrite be?

I have a serious appreciation for zeromq and I am excited to find out what
it can bring to Intel PIN! So I hope that you guys could give me a
realistic outlook on what that refactoring would entail...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140110/d2d9913e/attachment.htm>

More information about the zeromq-dev mailing list