Hi Ben.

Before you get too far into the details of using threads, can I ask why
you're considering it? The memory footprint and performance of using forked
processes with Perl is generally going to be better than that of threads,
due to copy-on-write.

- Perrin

On Mon, Apr 4, 2016 at 4:44 PM, Ben RUBSON <ben.rub...@gmail.com> wrote:

> Hello,
>
> I have some questions regarding mod_perl, threads, thread-safe functions,
> special vars scope...
>
> From
> https://perl.apache.org/docs/2.0/user/coding/coding.html#toc_Thread_environment_Issues
> :
> "if you chdir() in one thread, all other thread now see the current
> working directory of that thread that chdir()'ed to that directory"
> Do we speak about threads from threaded MPM ?
> (so the specific Apache process which owns the thread running this Perl
> script, and all its (the process) threads, will chdir()).
>
> From the same page :
> "Other usually problematic (non thread-safe) functions include readdir(),
> srand(), etc."
> Why readdir() would not be thread-safe ? I can't see why. Perhaps
> readdir() chdir() to read a directory content ?
> How could we then read dir content being thread-safe ?
>
> From
> https://perl.apache.org/docs/general/perl_reference/perl_reference.html#toc_The_Scope_of_the_Special_Perl_Variables
> :
> "In the mod_perl situation where the child server doesn't usually exit, if
> in one of your scripts you modify a global variable it will be changed for
> the rest of the process' life and will affect all the scripts executed by
> the same process."
> So in a threaded MPM, if one of the threads modifies one of the special
> Perl variables, it will instantly affect all other threads of this process ?
>
> What about variables like $? ? (return code of system() calls)
> And ${^CHILD_ERROR_NATIVE} ? (return code too)
> Does their value stay local to the thread ? / Does each thread have these
> variables with their own proper value ?
> Or is it unsafe to read them because they could be modified by another
> thread ?
>
> Thank you very much for your clarification,
>
> Best regards,
>
> Ben
>
>

Reply via email to