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