in reply to Re^7: Why Coro?
in thread Why Coro?

After a quick skim of the abstract confusions, enter the tangible! The fact that perl's ithreads have created a bunch of little pseudo-processes out of the threads! I'm not sure I'm convinced how forward-thinking it is to model processes by using threads. "Real" (OS-level) Processes already must explicitly share data. Processes have private data. Processes run their own interpreter. Process run in parallel. Why reinvent the wheel? Add in the escher-esque quality of starting an OS process to run perl, which creates a main OS/kernel thread... now perl's ithreads creates more OS/kernel threads which in turn act like separate perl processes. ithreads have their own interpreter, they share data through complex operations akin to IPC which means they are as fast as processes sharing data. This seems more like going backwards than forwards.

Yes, indeed! You're spot on here. This is exactly what ithreads are and it's what perlthrtut means when it says:

In this model, each thread runs in its own Perl interpreter, and any data sharing between threads must be explicit. The user-level interface for ithreads uses the threads class.

That line tells us everything we need to know and it's why I quoted it in my above post. You've just elucidated what the documentation has said in that line in a much clearer and more explicit way.

"its own Perl interpreter" -- That tells us it's not really a thread, but a separate process as a real thread isn't a complete copy with its own interpreter but a unit of execution inside a process that shares address space with other unique units of execution.

"data sharing between threads must be explicit" -- And finally this tells us that they don't share address space and if you want shared data you must do it by some other means just as you would between any other 2 separate processes. Ie the standard way with ithreads is using the complex operations as you put it, ie IPC.

Also, again, please don't respond to me Browser. This response is not aimed at you, but for Juster and the general community. I've heard all you've had to say on the matter and I respectfully disagree, so please refrain from attacks on me.

Replies are listed 'Best First'.
Re^9: Why Coro?
by BrowserUk (Patriarch) on Oct 27, 2010 at 13:27 UTC
    "its own Perl interpreter" -- That tells us it's not really a thread, but a separate process

    Each iThread, is simply another instance of the Perl interpreter running in it's own kernel thread within that same process.

    It is therefore not a "a separate process" in any way shape or form.

    "data sharing between threads must be explicit" -- And finally this tells us that they don't share address space

    All threads, including iThreads share the same, single address space of the parent process. The iThreads model ensures that only data explicitly marked as shared can be accessed from multiple threads. This mechanism protects the programmer from accidental shared-state corruptions. This is the same as the way Perl protects the programmer from "pointer problems" by not giving him direct access to machine level pointers. With the same benefits.

    so please refrain from attacks on me.

    This is not an attack on you, but rather, (as always), a correction of misinformation you are disseminating.

    As long as you feel the need to continue to do to disseminate such misinformation, I'll feel free to correct it.


    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.
    A reply falls below the community's threshold of quality. You may see it by logging in.