Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re^3: Standard way to convert timezone in multithreaded script

by zentara (Archbishop)
on Nov 24, 2009 at 12:58 UTC ( #809066=note: print w/replies, xml ) Need Help??


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

... i don't have a multi-cpu system to test on, but i accept your explanation that a single process can be running things across core boundaries.... but that seems quite insecure and it would seem to be a good kernel option to have ( like in the NSA-security kernel )...why?.... because according to your explanation, any process can start injjecting code into all the other cores of a multicore machine, just by starting a few threads..... how does this affect the nice value of the parent thread... does it increase according to thread count?....... what does it mean then to give a nice value to a script?... if the script can start spawning an infinite number of threads..... or what is to stop core hijacking by me spawning a thread until it gets into the desired core.... then executing something that halts the core, or other malicious intent...oO( maybe promoting threading is good for national security ;-) )

... my original intent was to point out that threads are not the fastest IPC out there, and continuing in that vein, there is Why use threads over processes, or why use processes over threads? and Threads versus fork, which to use? and Using forks and threads ...then choose the IPC right for you

..... by the way.... you would have no such POSIX module thread-safety in a fork-and-exec


I'm not really a human, but I play one on earth.
Old Perl Programmer Haiku
  • 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 tirwhan (Abbot) on Nov 24, 2009 at 14:33 UTC

    The security concerns you name are completely irrelevant. Any user who can execute code can hog all cores of a system, any time they want to, by starting processes that do so (unless you restrict them with something like ulimit, which works just as well on threaded processes). The kernels job is to keep the system running responsive enough so that other user processes and the system in general run well. Try running the line I sent, it'll work on a single-core system just as well. If you're running a reasonably modern version of Linux you may experience some slowdown on certain other applications, but your system should not grind to a halt, nor show real signs of unresponsiveness. That's the kernel doing its job, no reason to panic, business as usual.

    So all the talk about hijacking, injecting etc. completely misses the point of a multi-user system, yes you can do all these things with threads (if you're root), just as you could with processes. But no, it isn't a problem (if it were, by your reasoning, system security would be impossible on a single-core machine). The kernel only allows you as much access as the system policy dictates, and the system administrator sets system policy. You may have a point that multi-threaded apps can make things harder for the system administrator by obscuring what they're doing, because most Linux tools are built primarily with the multi-process model in mind. But, honestly, in over a decade of sysadmining multi-user systems I have never found this to be a problem.

    BTW, the nodes you link to aren't really pertinent to a discussion about threads vs. processes today, they're from 2003 (only the last one, which contains very little helpful discussion on the topic, is from 2006), a time when most people were still running Perl 5.6 and (if on Linux) a 2.4 kernel. Lots of things have changed since then, and any serious discussion on the topic would have to take these changes into account (I have no desire to hold such a debate, I find it pretty pointless).


    All dogma is stupid.
      BTW, the nodes you link to aren't really pertinent to a discussion about threads vs. processes today, they're from 2003

      .... that's not true..... the problems have not been totally solved..... just look at all the relatively recent nodes where threads are crashing due to module safety problems..... and most thread use involve modules


      I'm not really a human, but I play one on earth.
      Old Perl Programmer Haiku
        the problems have not been totally solved..

        That is correct, and I never said that using threads was without problems. But using nodes from 2003 to illustrate the problems with Perl threads today is somewhat like blaming Obama for sending troops to Iraq, or criticising Einstein for the limits of classical mechanics. Things have moved on since then, and any serious discussion would have to take these changes into account.

        If you're interested in seriously criticising the usage of threads in Perl programs you should first read up on their current implementation as well as the way threads and processes are handled in multitasking, multi-user operating systems(*). Judging by your posts in this thread (especially your latest reply to BrowserUK) you really have a lot of reading to do, you do not seem to understand how multi-user operating systems work on a fundamental level, and my attempts to explain a few things were obviously fruitless.

        (*) I heartily recommend Linux Kernel Development(link is for the upcoming 3rd edition), it goes into a lot of depth but also gives you a clear technical view on how the Linux kernel works and why it works that way.


        All dogma is stupid.
Re^4: Standard way to convert timezone in multithreaded script
by BrowserUk (Pope) on Nov 24, 2009 at 17:04 UTC

    You need to look up "Ingo Molnar" and "Native POSIX Thread Library (NPTL)" and read (a lot!), before you expose the depth of your misunderstanding even further.


    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.
      .... i'll take your word for it in Re: Why use threads over processes, or why use processes over threads? which is in an interesting about face from your current position

      BrowserUk states:

      The result is, that perl threading implementation as is, is at best utilitarian, and at worst, broken. This is unsurmountable given the nature of perl's core as is, and would only be fixable with a complete re-write of the perl core. The problem runs very deep. Even the POSIX C-runtime that underlies so much of the perl core is inherently non-reentrant, and without reentrancy built-in from the lowest levels, making effective use of threads, where these are natively fast and efficient, simply isn't possible.

      .... i dunno where my ignorance comes from...maybe you?


      I'm not really a human, but I play one on earth.
      Old Perl Programmer Haiku

        Articulated lorries (semi trucks) are much bigger and slower than F1 or Indy cars. Diesel-electric freight trains even bigger and slower.

        But, it doesn't mean that any time someone has a minor problem with their truck (the satnav in my truck sometimes looses the gps signal), or train (the horn on my loco sometimes sqeaks rather than bellows), that the appropriate response is: Trucks (trains) are big and slow; what you need is an F1 car!

        To advise which of those two extremes, or where between them, is the most appropriate tool for the OPs problem, requires that you first have some information regarding that problem. And then the best advice will depend upon the problem being tackled.

        It's all about giving an appropriate response to the question asked. For the OPs question, that was that his apparent expectation that changing the value of $ENV{TZ} would directly and immediately affect the behaviour of localtime, is misplaced.

        Descending into a rant that he should not be using threads, when there is zero information in his OP of what or how he is using threads, is simply an inappropraite response. Doing so in the basis of your near total misunderstanding of the subject of your rant is ...


        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.
        Its not like I understand, but that is from Nov 11, 2003 and today is Nov 24, 2009 , so something changed in 6 years? Oh wow.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://809066]
help
Chatterbox?
[choroba]: :-)

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (8)
As of 2017-10-23 16:26 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My fridge is mostly full of:

















    Results (281 votes). Check out past polls.

    Notices?