I didn't know there was an aspect-oriented programming library for native code. That's interesting.
Is the problem that you want to user 0MQ in a callback that might be triggered by thread creation, and yet using 0MQ causes thread creation, therefore triggering a recursive condition? This might not be as bad as it seems if you put the 0MQ context into a singleton. Threads are only created when the context is created, which would only happen once. On Fri, Jan 10, 2014 at 5:43 PM, Kenneth Adam Miller < [email protected]> wrote: > 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 > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
