Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Re^11: Utter FUD!

by ikegami (Pope)
on Oct 27, 2010 at 07:25 UTC ( #867636=note: print w/replies, xml ) Need Help??

in reply to Re^10: Utter FUD!
in thread is ||= threadsafe?

By common definition of threads, a process's variables are shared among all threads. (Wikipedia says: "In particular, the threads of a process share the latter's instructions (its code) and its context (the values the various variables have at any given moment).") That's not the case with threads, thus the term "fork emulation". It has nothing to do with the point at which execution starts. Yes, it's not a very accurate term, but it's not a slur either.

Replies are listed 'Best First'.
Re^12: Utter FUD!
by BrowserUk (Pope) on Oct 27, 2010 at 07:37 UTC
    By common definition of threads,

    In C yes. How about Erlang? Or Haskell? Or Java? Or.... Why should Perl alone have to have to copy C?

    iThreads are not simple Kernel threads. They could not be so in an interpreted language with fat variables.

    But neither are they new processes--forks defining characteristic--so any allusion to that is simplistic, inaccurate and deliberately misleading.

    You might wanna get off of those coat-tails....

    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.

      Java, yes. C++, yes. Modula-2, yes. I don't know Erlang and Haskell.

        Erlang "threads" are also called Erlang "processes" and they neither have shared data/state nor wholesale copies of data. I don't often see them referred to as just "threads", probably because they aren't much like C, nor C++, nor Java, nor Modula-2, nor Visual BASIC, nor Unix kernel threads nor Win32 native threads (nor are they much like iThreads nor fork).

        You can create and destroy Erlang "processes" similar to what one might be used to with threads in a procedural language (since Erlang is functional but also is all about interfacing with things in the Real World).

        Haskell has more emphasis on the "functional" (the meaning from computing theory, not plain English) and less on the "interfacing" and so "threads" there tend to be more just purely useful for using more CPUs at once in hopes of finishing sooner and you don't so much control the "threads" as you declare where the compiler is allowed to make use of threads for you.

        Purely functional programs don't have a traditional flow, traditional "blocking" operations, nor variables much less shared variables, so traditional threads just don't really apply much.

        A lot of times you'll see things called "threads" with some qualifier(s) and then described as "not the same as 'vanilla' threads" and then called "light-weight processes". Unfortunately, you can't call iThreads "light-weight processes" since in some significant ways they weigh more than vanilla processes.

        So, iThreads are actually more like fork than like any of these things that are sometimes calls "threads" in other languages. And the things that aren't pretty much exactly like C threads and Unix kernel threads don't tend to get called just plain "threads" much, IME.

        Though, their emulation of the lion's share of work done by fork() (copy of the majority of the process, not the myriad bookkeeping bits like setting the program counter or assigning PIDs, etc.) is significantly less efficient than fork().

        iThread's copying used 10x more CPU in the trivial case. It was trivial to create some data and make iThread's copying use 100x the CPU of fork(). Even if I pessimize for fork() by modifying all of the initial data so it all gets unshared, iThreads still used just over 70x more CPU.

        Comparing memory usage is not trivial so I didn't try to come up with any numbers to compare that.

        But that only applies to (part of) why I don't use iThreads in Unix. I look forward to trying to use iThreads again under Windows.

        The name iThreads has probably discouraged use of the technology. I find many eschew threads, often in a rather stark "threads vs fork" mindset. Well, iThreads have more in common with multi-tasking via fork than with traditional multi-tasking via threads, so an ardent "fork not threads!" stancer should well consider iThreads, certainly before threads.

        I tend to focus more on the details of communication between the parts (solid interfaces lead to solid systems) and so don't tend to reach for the convenient "share a few variables willy, nilly" framework. But iThreads have advantages and can be used effectively even in Unix (yes, you usually need to be aware of their disadvantages; for example, don't spawn a new thread for each little task).

        - tye        

        Java, yes. C++, yes. Modula-2, yes

        That's like picking Robin, Maurice & Barry to represent all the musicians in the world.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://867636]
[jedikaiti]: Cool!
[Cow1337killr]: <p>stevieb, you should leave an insightful comment at https://plugins. idea/plugin/7796- perl</p>

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (7)
As of 2017-02-20 20:59 GMT
Find Nodes?
    Voting Booth?
    Before electricity was invented, what was the Electric Eel called?

    Results (302 votes). Check out past polls.