|
in reply to Re^3: Standard way to convert timezone in multithreaded script
in thread Standard way to convert timezone in multithreaded script
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.
|
Re^5: Standard way to convert timezone in multithreaded script
by zentara (Archbishop) on Nov 24, 2009 at 17:36 UTC
|
.... 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?
| [reply] |
|
|
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.
| [reply]
[d/l] |
|
|
... yeah soory BrowserUk... i concede that you have every right to jump on my case for what i said.... sorry if i spewed some ignorance about the functioning of multi-core motherboards, but i don't have one...i do wonder about the wisdom of allowing a process to launch threads into other cores, other than the one it's parent exists in..... i'm in that zen trap, where the external world becomes a reflection of the inner mind, and i use this as a guide to developing my artificial intelligence strategy.
..... and in my inner mind, i have distinct barriers between cores ( so to speak)...... my visual cortex dosn't allow the audio core processing to occur in the visual core... etc.... a separation for safety.... and in that train of thought, i require that i can reset a single core, without resetting the whole set of cores...... if my collision-detection system goes bonkers, i don't want it to affect my steering...etc. .... and i don't want to have to deal with worrying that maybe the collision-detection code somehow got it's malfunctioning code into my steering core
.... but i guess for gamers, or pure dedicated number crunching, this cross-core core chaos would allow more speed.... but at a risk
.... another point that seems troublesome, is that can you be sure that the thread spawned will go into another core?.... for instance.... to use tirwhan's 1-liner as an example..... he says as you spawn muliple threads, they automatically get assigned to other cores..... but what if one core is already heavily loaded?..... wouldn't the scheduler tend to drop more than one thread into one of the unloaded cores?....... or is there a way to specifically direct which core the code block goes into?..... otherwise 8 threads could end up like 1 in cpu0, 3 in cpu1 , and 4 in cpu2 because cpu5 thru 7 are already running a heavy load
.... anyways..... it seems like all this multicore cross-core-exection stuff is aimed at gamers, and a security grade processor would automatically deny this behavior to confine all bad-acting apps and their spawn( whether it be forks or threads) to the originating core
....but maybe i'm just an old dog, whose is more worried that someone is going to steal my bone, than moving my bones around faster ...... fwiw... my spaceship controls have core separation :-)
| [reply] |
|
|
|
|
|
|
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.
| [reply] |
|
|
