Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

comment on

( #3333=superdoc: print w/replies, xml ) Need Help??
If I'm not mistaken, the previous implementation of threads tried the "share all" way and failed miserably so the ithreads were developed to have something that, even if heavy, at least ... works.

I'm not advocating the "share all" way. Absolutely not. Actually what I'm advocating is share less. Indeed, only share what I ask to share; and only when I ask to share it.

What makes iThreads heavy, is not the threads, nor the 'protected' memory of normal lexicals; it is the wholesale cloning of the process global state -- %ENV, file&dir handles, special global variables; etc. etc. -- every time you start a thread. What I'm advocating it to skip all of that entirely. It only makes sense because they are trying to emulate fork, where all that stuff has to be cloned, because you're starting a new process, so the new process cannot access the process global state of its parent. That simply isn't true of a new thread; and duplicating (for example) stdin/stdout/stderr simply makes no sense. having cloned them, they are still connected to the same place, printing from one thread still conflicts wth printing from another thread, so what did you gain by cloning them? Nada.

And the second thing that makes threads "heavy", is the duplication of everything that has been loaded, or instantiated into the current thread before the clone. This is *never* what I want in a new thread. Again, this only makes sense in the context of fork emulation; and fork emulation only makes sense if it allows unix scripts that use the forking paradigm to run unchanged on the emulating platform -- ie. windows -- but it doesn't! Signals would have to accurately emulated; and they aren't (and probably can't be!). Non-blocking IO would have to work the same; (it could be made to, but it doesn't). The fork emulation is almost completely useless.

But interpreter threads with complete segregated memory, works. And works well. So well in fact that the concept is being used in just about every new programming language that provide kernel threading. And, as you mentioned, and as the previous Perl threading experiment proved, given the nature of the old-fashioned programming style used by Perl's internals -- global state ($/,$\,$" etc.); static tables & god objects; non-reentrant functions et al. -- it is the only way to retro-fit threads into it.

But completely isolated threads throws away one of their major advantages: the ability to use divide and conquer threads upon (shared) large, homogeneous datasets. So you need a way to share state; which is currently implemented by threads::shared, but in a decidedly non-optimal way.

Now imagine that instead of the indiscriminate cloning required by the useless & unused fork emulation, you put all shared state -- all the globals and environment in addition to the shared lexicals -- into a single SHARED::* stash (similar to what is done for shared lexicals now, but with the addition of the process global entities (GSEs)), and then modify the GV* functions to lock and access that SHARED::namespace whenever a GSE is accessed.

Bingo! Isolated, interpreter threads, clean and empty at the point of spawning, with full, controlled access to GSEs. With a sensible implementation of thread::shared::tie to avoid the gratuitous use of memory that it currently uses, and you end up with threads that start faster & lighter, and have full access to GSEs and lightweight shared memory, whilst retaining the implicitly non-shared state of normal lexicals.


With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
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.

In reply to Re^6: Trying to Understand the Discouragement of Threads by BrowserUk
in thread Trying to Understand the Discouragement of Threads by benwills

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (3)
As of 2022-09-29 01:43 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    I prefer my indexes to start at:




    Results (125 votes). Check out past polls.

    Notices?