[zeromq-dev] Rewriting zeromq internal thread management
Lindley French
lindleyf at gmail.com
Fri Jan 10 23:54:09 CET 2014
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 <
kennethadammiller at gmail.com> 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
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140110/1788a893/attachment.htm>
More information about the zeromq-dev
mailing list