Re: Why use threads over processes, or why use processes over threads?

non reentrant nature of perl's core

This non-reentrant nature of perl's core goes much deeper than many people realize. It's not that there's a bunch of function that are reentrant, and that perl now has to call the *_r equivalents. It goes deeper. Even things that on the Perl level are static are non-reentrant. Like fetching the value of a scalar. For instance, print $var can't be done in parallel, because $var might not have the pOK flag set, which means the Perl has to convert the numerical value of $var to a string value - which means that the underlaying datastructure is modified. (This is the reason why variables are not shared by default).

Abigail

Comment on Re: Why use threads over processes, or why use processes over threads? Select or Download Code

Replies are listed 'Best First'.
Re: Re: Why use threads over processes, or why use processes over threads? by BrowserUk (Patriarch) on Nov 11, 2003 at 14:22 UTC
Agreed. I recently spent a lot of time exploring ways of trying to untilise threads more effectively (under Win32), and discovered the nature and scale of the problem. It hasn't put me off of the benefits of threads over processes in my environment, nor in the wider context where they are a natural part of the system. It has, however, put me off of trying to utilise them to any great extent from perl. They still have their utility under Win32, as the absence of a native fork, means that there is little or nothing to choose between forking and threading, but using threads does expose a little (very little) more control of the multi-processing facilities than the fork emulation. I wish I could be more enthusiastic, but the deep rooted nature of perl's non-reentrancy, as you noted, make it near impossible to improve the situation, give the current implementation of perl. From what I have understood of the Parrot architecture, the objectification of the fundemental types, should mean that it would (will?) be possible to cheaply and transparently serialise access to individual scalars. Embedding a semaphore within every scalar, and using it for every write operation may sound horrendous, but applied at the core level, it shouldn't be that problematic or costly. However, if it is not done at the core level, trying to retroactively add it would be disasterous. Time will tell, but I won't be holding my breath. Examine what is said, not who speaks. "Efficiency is intelligent laziness." -David Dunham "Think for yourself!" - Abigail Hooray! Wanted!	[reply]

Replies are listed 'Best First'.

Re: Re: Why use threads over processes, or why use processes over threads?
by BrowserUk (Patriarch) on Nov 11, 2003 at 14:22 UTC

Agreed. I recently spent a lot of time exploring ways of trying to untilise threads more effectively (under Win32), and discovered the nature and scale of the problem. It hasn't put me off of the benefits of threads over processes in my environment, nor in the wider context where they are a natural part of the system. It has, however, put me off of trying to utilise them to any great extent from perl.

They still have their utility under Win32, as the absence of a native fork, means that there is little or nothing to choose between forking and threading, but using threads does expose a little (very little) more control of the multi-processing facilities than the fork emulation.

I wish I could be more enthusiastic, but the deep rooted nature of perl's non-reentrancy, as you noted, make it near impossible to improve the situation, give the current implementation of perl.

From what I have understood of the Parrot architecture, the objectification of the fundemental types, should mean that it would (will?) be possible to cheaply and transparently serialise access to individual scalars. Embedding a semaphore within every scalar, and using it for every write operation may sound horrendous, but applied at the core level, it shouldn't be that problematic or costly. However, if it is not done at the core level, trying to retroactively add it would be disasterous.

Time will tell, but I won't be holding my breath.

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
Hooray!
Wanted!

[reply]