Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re: Status and usefulness of ithreads in 5.8.0

by Abigail-II (Bishop)
on Jul 15, 2002 at 09:32 UTC ( #181723=note: print w/replies, xml ) Need Help??


in reply to Status and usefulness of ithreads in 5.8.0

  • "Thread" is a buzzword, fork isn't. Of course, fork has clocked over 30 years of mileage, while threads are the new kid on the block.
  • Threads have been invented and reinvented. So we have kernel threads, green threads, posix threads, interpreter threads, etc. It's just like Java, it never works the same twice. fork is just fork, you just pull out your Stevens or other book from your bookshelf, and it just works reliably, with a clear and simple interface.
  • Inferior OSses don't have fork.
  • Threads mangle each others variables by default, and you need to explicitely guard yourself against that from happening. (Note that just *looking* at a variable can mean Perl changes the variable under the hood - it's not a safe operation.) fork is safe for your data, you need to explicitely share data (using shared memory for instance).
  • Compared to a select() loop (as provided by for instance POE), threads give you underterministic behaviour, while a select loop gives you deterministic behaviour.
  • Do you know which thread is going to handle a send signal? On any signal capable OS? I know when I fork().

Replies are listed 'Best First'.
Re: Re: Status and usefulness of ithreads in 5.8.0
by djantzen (Priest) on Jul 15, 2002 at 11:20 UTC

    What exactly are you criticizing? Windows? (What makes an "inferior OS"?) Java? No, threading is not just a buzzword, and it frankly doesn't matter that threads have gone through many changes through the years. The history of threads demonstrates that they are not the "new kid on the block". So they've evolved over the years; this is not a useful critique. Threads, at least in their contemporary manifestations as in Win32, Java, and ithreads as of Perl 5.6, allow lightweight and highly manageable distibution of resources -- especially when it comes to interpreted languages due to the overhead of the interpreter or virtual machine -- whereas forked processes are more memory intensive and more difficult to work with. The difference between interprocess and intraprocess communication is a big one.

    It's just like Java, it never works the same twice

    Really? Core Java has been stable since at least 1997. If you want to criticize Java's stability, please look first at Java extensions like Swing, J2EE, or the implementation of (the recently added) anonymous inner classes. And by the way, threads were built into the language from its very inception, in fact one of the revolutionary aspects of Java was the fact that Gosling/Sun realized the usefulness of threads early on and built that capacity into the language for the 1.0 release. Abigail-II, if you're going to slander another programming language, at least make it believable.

    Threads mangle each others variables by default, and you need to explicitely guard yourself against that from happening.

    The benefit of threading as opposed to forking processes is shared memory space, and that's why Java and threading packages in C++ and Win32 support code that is thread safe. The bottom line is that it's a trade for efficiency in memory usage in exchange for the extra effort it takes to type "sychronized" in your method declarations.

    I for one am glad that thread support in Perl is progressing, and that it will be fully realized in Perl 6.

Re: Re: Status and usefulness of ithreads in 5.8.0
by BazB (Priest) on Jul 15, 2002 at 13:21 UTC

    Threads mangle each others variables by default

    Not according to perldoc threads:

    It is very important to note that variables are not shared between threads, all variables are per default thread local. To use shared variables one must use threads::shared.

Re: Re: Status and usefulness of ithreads in 5.8.0
by BrowserUk (Pope) on Jul 15, 2002 at 19:12 UTC

    I wrote my first multi-threaded app under OS/2 v1.0 in early 1987 whilst working at IBM. The os (at that time called CP/DOS) was still so early in it development the only IO possible was Beep(frequency,duration). Proving that multiple threads were running meant having each thread beep at a different pitch and/or tempo. WinNT is a successor to/deriviative of the same core mechanisms as were developed for OS/2.

    They have come a long way in the last 14 years. The 'problems' of synchronisation and re-entrancy are well understood and easily handled.

    There are many good reasons to knock Win32. Braindead CLP, bloat, undue care and attention to security issues and fixes. All that source under the lock & key of one of the most predatory companies around.

    There seems little benefit in constructing specious arguments against the threading, critical sections and semaphore mechanisms. Some of the bits they actually got right.

Re: Re: Status and usefulness of ithreads in 5.8.0
by BrentDax (Hermit) on Jul 15, 2002 at 22:08 UTC
    Threads mangle each others variables by default, and you need to explicitely guard yourself against that from happening. (Note that just *looking* at a variable can mean Perl changes the variable under the hood - it's not a safe operation.) fork is safe for your data, you need to explicitely share data (using shared memory for instance).

    Not true. Variables under ithreads (what threads.pm implements) need explicit sharing. (You do this by saying my $variable : shared.) The difference is that Perl still manages your variables, so you don't have the problems inherent in using normal Unix IPC (such as it not meshing well with Perl).

    Do you know which thread is going to handle a send signal? On any signal capable OS? I know when I fork().

    I'm not sure about this, but I think Perl 5.8's new safe signals have a way to deal with this.

    =cut
    --Brent Dax
    There is no sig.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://181723]
help
Chatterbox?
[Corion]: choroba: spod5 converts pod to S5 HTML, so it's also still basic. I find the lack of animations (in the sense of "highlight this", "highlight that" in code) somewhat tedious as I do it with rendered PNGs
[Corion]: I haven't found a good way to include/use the source SVGs I use for creating the PNGs directly as animations
[ambrus]: Presentations come in many different shapes, and so slides do as well.
[Corion]: Doing that in Powerpoint or Ooxml would be nice(r) but I'm much quicker doing the outline of a presentation and the code as Pod
[Corion]: Hurrr - on a machine that is behaving weirdly, I have two processes CROND running. I guess that is the source of unattended jobs sometimes not finding their files anymore...
[ambrus]: Most of the time if I make slides, they're just a formatted document with a medium level of formality (between a well written article and an informal draft), with usually the page breaks chosen carefully and possibly some content repeated between pages.
[Corion]: ambrus: My slides are mostly a list of things I want to talk about. But sometimes I want to point out interesting parts, or build up a larger image from small components. This is where animations/ highlights would come in well
[choroba]: what I like about slides in HTML + CSS is I can use templates to produce them, which means all code in slides is tested, and I can version them in git
[ambrus]: Btw, a request to everyone who organizes international conferences where presenters will show slides.
[ambrus]: In the document where you tell people how long the presentations are supposed to be, please also tell the aspect ratio of your projectors, because that's not obvious in advance.

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (12)
As of 2017-09-26 10:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    During the recent solar eclipse, I:









    Results (293 votes). Check out past polls.

    Notices?