in reply to Re^8: threading a perl script
in thread threading a perl script

Whilst the mechanisms are similar, the devil is in the detail.

To see the differences, contrast win32\perlhost.h(1830)PerlProcFork(struct IPerlProc* piPerl) and threads.xs ithread_create(...)


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^10: threading a perl script
by vkon (Curate) on Apr 25, 2011 at 06:29 UTC
    in threads.xs I see
    thread->interp = perl_clone(aTHX, CLONEf_KEEP_PTR_TABLE | CLONEf_C +LONE_HOST);
    in win32\perlhost.h(1830)PerlProcFork I see
    PerlInterpreter *new_perl = perl_clone_using((PerlInterpreter*)aTH +X, CLONEf_COPY_STACKS, h->m_pHostperlMem, h->m_pHostperlMemShared, h->m_pHostperlMemParse, h->m_pHostperlEnv, h->m_pHostperlStdIO, h->m_pHostperlLIO, h->m_pHostperlDir, h->m_pHostperlSock, h->m_pHostperlProc );
    well, instead of perl_clone there is a call to perl_clone_using. and perl_clone calls perl_clone_using.
    This does not surprise me - this is what I actually expected to see.

    So, I still fail to see why my misunderstanding is manifest.

      this is what I actually expected to see.

      So till now you hadn't looked. So, you were assuming.

      But, even now you have seen, I think you are still not really seeing or you would not say:

      I still fail to see why my misunderstanding is manifest.

      If you understood what you have now seen. That is, if you were appreciating the implications of the differences between the two pieces of code you've posted.

      Perhaps this will fill in some of the blanks.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
        Yes, you're correct -
        I was assuming that 1) threads.xs and 2) fork - they both use same underlying engine - ithreads.
        I even not bothered to look into implementation details, as it was just enough granulation of details for my particular purposes

        Now you're stating that 1) my misunderstanding is manifest and 2) devil in details.

        Now this boils down to one of things:

        • either, when looking into deep into implementation details I will see that 'fork' and 'threads.xs' are really different beasties, due to devils in details
        • or, looking into API that is followed by your link I will eventually understand deep differences between 'threads.xs' and 'fork'
        what should break my wrong assumption?
        I still fail to see a point of my misunderstanding.

        Actually I am inclined to think that my phrases were not clear , they were too vague, due to my English language imperfection, and - so - I do not have deep misunderstanding.

        I.e. I do not know about exact implementation details, but I do know that both are using 'ithreads'.