in reply to Re: Why use threads over processes, or why use processes over threads?
in thread Why use threads over processes, or why use processes over threads?

Modern kernels on CPUs with modern MMUs can fork processes with very little effort and switch them pretty quickly.

Win NT (any version) processes are quite expensive, and a significant amount of Perl code runs on Win2k web servers. This is a stark contrast with Linux, where processes are very cheep (they have to be, since Linux threads are almost identical to processes).

Forked processes default to not sharing; threads default to sharing everything . . . correct approach to security is to disallow by default.

I don't think you can make the analogy between taking user input and a process/thread model. In taking data from (for example) a CGI form, you usually have no idea where the information is coming from, so it is reckless to not validate it. In sharing data between processes, you presumably control everything that happens between the two processes. The data shared is no less untrustworthy than the data you pass between subroutines. If you happen to be in a situation where you don't control what happens in one of the procesess or threads, then you definatly need to do validation. However, I doubt such a situation pops up much.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

: () { :|:& };:

Note: All code is untested, unless otherwise stated

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

Replies are listed 'Best First'.
Re^3: Why use threads over processes, or why use processes over threads?
by Aristotle (Chancellor) on Nov 11, 2003 at 19:19 UTC
    Win NT (any version) processes are quite expensive
    Windows doesn't even have forks, so the point is moot anyway. Notice how the Perl 5.6 thread model was largely an attempt to emulate fork() for platforms which don't have it (even if that wasn't its stated goal, it certainly made that impression).
    In sharing data between processes, you presumably control everything that happens between the two processes.
    "Presumably" being the keyword, because this is about the effect of a) bugs and b) security holes. With threads, both occurences can kill off your entire application. With forked processes, they can only affect the child in question except where a resource is explicitly shared.

    Makeshifts last the longest.

[reply]

In Section Meditations