[zeromq-dev] Rewriting zeromq internal thread management

[Kenneth Adam Miller]

Well, I think you don't understand what Pintools precisely do; you're
pretty close to an aspect-oriented programming library, but see this isn't
a language level facility; it's an assembly level facility, and it doesn't
not require (nor operate upon) source code. Aspect-oriented programming
absolutely requires source (at least in the conventional sense that I know
of it as). But you're really close :) (it is a recursive condition in a
way).

Let me simplify my question; the problem is that the native library
calls-whatever they are that aren't literally that one function that I
described-that zeromq uses internally to spawn threads are actually sort of
creating a double jeapordy problem almost like what you've described; the
PIN instrumentation tool tracks the target application, but if you use
native library facilities for managing threads and other stuff, then the
PIN instrumentation runtime can't distinguish between the threads spawned
that are instrumentation/analysis side code and the target, which should be
tracked. Thus, you have code that should facilitating managing the data
gathered or whatever from the target, and then you're instrumenting your
own analysis/management thread, which is ignorant because you don't even
want that data for one (and because it's possibly recursive, but may not be
depending on how you wrote it).

To be honest, that singleton approach sounds good, but I still absolutely
have to have that thread spawned by the function described. I need to know
what it would take to either restrict zeromq from spawning any threads
(just run synchronously ok, I will write my own pin thread that loops
around sending output and manages a queue, it's fine). Or possibly forcing
zeromq to use the function, that works too, but I think that refactoring
would be arduous and time consuming. So if I rewrite zeromq internals at
all, I want a single spawn function to redefine to encapsulate the PIN
function I use, and even then I need to know that ZeroMQ doesn't spawn any
threads other than when I know about it precisely. What would that require?

By the way, thanks so much for the help. Sharp cat! :)))


On Fri, Jan 10, 2014 at 4:54 PM, Lindley French <lindleyf at gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/18f0fe41/attachment.htm>