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...
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
