in reply to Re^2: Standard way to convert timezone in multithreaded script
in thread Standard way to convert timezone in multithreaded script

I can't see where my XS code is aware of threads, except of calling localtime_r() instead of localtime(), but perl manuals says somewhere that if you compile perl with 'useithreads', it will automatically use those *_r() functions.
  • Comment on Re^3: Standard way to convert timezone in multithreaded script

Replies are listed 'Best First'.
Re^4: Standard way to convert timezone in multithreaded script
by BrowserUk (Patriarch) on Nov 25, 2009 at 08:41 UTC

    Looking more closely at your code above, there is something strange going on that I do not understand.

    In this part of the main thread, you change the value of $ENV{TZ} twice: 

    $ENV{TZ}="Europe/Paris";
my $t=localtime();
print "main (Europe/Paris): ",$t,"\n";

$ENV{TZ}="Europe/Moscow";
$t=localtime();
print "main (Europe/Moscow): ",$t,"\n";

    [download]

    But nowhere in that part of the code do you call tzset(), nor any of the functions in your XS code. And yet, according to the console output you've posted: 

    main (Europe/Paris): Tue Nov 24 23:27:28 2009
main (Europe/Moscow): Wed Nov 25 01:27:28 2009

    [download]

    The output from localtime is somehow affected. Which is exactly what didn't happen originally that caused you to post your OP?

    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.
[reply]
[d/l]
[select]

      XS code contains four calls to tzset()

      Perl code running in main thread works pretty well without calling POSIX::tzset. I believe this is due to how tzset()/localtime() in libc works.

      'man tzset' says "This function is automatically called by the other time conversion functions that depend on the time zone."

      So, there is no wonder why this works in main thread. And in child threads tzset needs to be explicitly called for changing timezone, but really works only when called in XS code. I don't know why, I just managed to find this fact :)

      Also, I did not tried it on other OSes or even on another linux distro or with different libc versions or versions of perl other than 5.10.0

      My environment is CentOS 5.2, libc-2.5, perl-5.10.0

[reply]
        Oh-uh, my XS code is wrong. Just calling malloc() in threads is dangerous. I'll post corrected code as soon as it really will work :)
[reply]
        My environment is CentOS 5.2, libc-2.5, perl-5.10.0

        I've been playing with 5.10.1 under Ubuntu 9.10: 

        mehere@mehere-desktop:~/test$ gcc --version
gcc (Ubuntu 4.4.1-4ubuntu8) 4.4.1
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There i
+s NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PUR
+POSE.

        [download]

        ...but, as a guest running within a VirtualBox on a Vista host.

        Ie. I have little faith that anything that works (or fails) here will produce the same results under any other circumstances :)

        (P.S.) You aren't the first to be bitten by the "malloc thing" in XS code. Truth beknown--if they'd all admit to it--we've all been there.

        Your discovery regarding not requiring tzset() in the main thread are interesting. It stimulates several possibilities. And when I am less sleep deprived, I may persue them to a (minorly) significant conclusion.

        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.
[reply]
[d/l]
[select]

      But nowhere in that part of the code do you call tzset(),

      And adding them doesn't help.

[reply]

In Section Seekers of Perl Wisdom