[zeromq-dev] Rewriting zeromq internal thread management

[Kenneth Adam Miller]

Oh sorry about that too, you answered my second question. Crap I didn't
realize how bad lack of sleep makes you think ugh.

Ok, so then the refactoring... that's just up to me apparently. Apologies.
I'll hunt down that function and see if I can alter it.


On Fri, Jan 10, 2014 at 5:24 PM, Kenneth Adam Miller <
kennethadammiller at gmail.com> wrote:

> Oh wait, you kind of described it really closely to what it is...  my bad.
> Hey I skipped sleep doing a development iteration, so I apologize lol
>
>
> On Fri, Jan 10, 2014 at 5:14 PM, Kenneth Adam Miller <
> kennethadammiller at gmail.com> wrote:
>
>> 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/54f24e07/attachment.htm>