[12389] in Perl-Users-Digest
Perl-Users Digest, Issue: 5989 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jun 14 14:07:25 1999
Date: Mon, 14 Jun 99 11:00:32 -0700
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 14 Jun 1999 Volume: 8 Number: 5989
Today's topics:
@INC bizarreness jwwilhit@srp.gov
A few questions <mayes+@andrew.cmu.edu>
Re: a thread on threads (Marcel Grunauer)
Re: a thread on threads <tchrist@mox.perl.com>
Re: a thread on threads <gbartels@xli.com>
Re: another href extraction question! <paul.bunkham@synetica.com>
Databases!! HELP!! dragnovich@my-deja.com
Re: Databases!! HELP!! <craig@mathworks.com>
Re: DIFF BETWEEN PERL & CGI (Hasanuddin Tamir)
Re: dimensions of a jpg file <dscapin@harris.com>
Re: dimensions of a jpg file <dscapin@harris.com>
Re: dimensions of a jpg file <dscapin@harris.com>
Re: Dynamic Regular Expression (Bart Lateur)
Re: Dynamic Regular Expression <tchrist@mox.perl.com>
Special: Digest Administrivia (Last modified: 12 Dec 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 14 Jun 1999 16:26:38 GMT
From: jwwilhit@srp.gov
Subject: @INC bizarreness
Message-Id: <7k3aff$su1$1@nnrp1.deja.com>
Why is it if I run /usr/sbin/perl from the command line and type the
following command:
print "@INC\n";
I get the following:
/usr/freeware/lib/perl5/5.00502/irix-n32
/usr/freeware/lib/perl5/5.00502
/usr/freeware/lib/perl5/site_perl/5.005/irix-n32
/usr/freeware/lib/perl5/site_perl/5.005
/usr/freeware/lib/perl5/sgi_perl/irix-n32
/usr/freeware/lib/perl5/site_perl .
But when I run a script that is using the GD module I get the following
error message (it errors out on any add-on module I try and use not just
GD...GD happens to be first in line). BTW...The script uses
#!/usr/sbin/perl:
Can't locate GD.pm in @INC (@INC contains:
/usr/share/lib/perl5/irix-n32/5.00404
/usr/share/lib/perl5
/usr/share/lib/perl5/site_perl/irix-n32
/usr/share/lib/perl5/site_perl
/usr/share/lib/perl5/sgi_perl .) at ./usgsGrph.cgi line 11.
BEGIN failed--compilation aborted at ./usgsGrph.cgi line 11.
Maybe I'm just an idiot (and that is entirely possible!) but it looks to
me like there is a discrepancy between the two @INC statements. I've
tried recompiling all of my add-on modules and reinstalling them, I've
reinstalled perl...No luck.
Any help would be greatly appreciated.
Also...this script runs perfectly on a different machine that seems to
be configured similarly to the machine I'm having problems on.
-Jason
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Mon, 14 Jun 1999 12:54:34 -0400
From: Jonathan J Mayes <mayes+@andrew.cmu.edu>
Subject: A few questions
Message-Id: <QrNHD_600Ui805NVQ0@andrew.cmu.edu>
Hi,
I'm putting together a little memo for my boss concerning perl compiling,
perl executables,etc. I'm having a hard time finding anything in the
FAQ's or the general web dealing with these topics. Also equally
evasive or any articles on C/C++/Perl integration. Can anyone point out
a good site or sites to visit to aid my search?
thanks,
jm
------------------------------
Date: Mon, 14 Jun 1999 16:43:21 GMT
From: marcel.grunauer@lovely.net (Marcel Grunauer)
Subject: Re: a thread on threads
Message-Id: <37652f7e.12356728@enews.newsguy.com>
On Mon, 14 Jun 1999 10:44:19 -0400, Greg Bartels <gbartels@xli.com>
wrote:
>Can anyone give me the lowdown on threading in perl?
>last perl installation I did prompted me as to
>whether I wanted to use threads or not, and that
>threading was still experimental/not stable.
>this was about a month or so ago.
>
>is there an URL I could go read up on the
>current status of threads? who's working on
>it? how portable will it be? what will
>threads allow me to do exactly? etc?
>
>I'm working on a problem that seems might
>be well easily solved by threads, if I
>understand what threads will be able to do.
>
>Greg
Well, for a start there's Dan Sugalski's perlthrtut, available as part
of the new documentation for 5.005_57, or on
http://language.perl.com/misc/perlthrtut.html.
Also check the Thread.pm documentation.
There is also an article on threads on
http://www.heise.de/ix/artikel/1998/10/154/default.shtml, although
it's in German, so it might or might not be of any use to you.
Hope this is "useful" :-)
Marcel
------------------------------
Date: 14 Jun 1999 11:38:02 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: a thread on threads
Message-Id: <37653dfa@cs.colorado.edu>
[courtesy cc of this posting mailed to cited author]
In comp.lang.perl.misc, Greg Bartels <gbartels@xli.com> writes:
:Can anyone give me the lowdown on threading in perl?
:last perl installation I did prompted me as to
:whether I wanted to use threads or not, and that
:threading was still experimental/not stable.
:this was about a month or so ago.
:
:is there an URL I could go read up on the
:current status of threads? who's working on
:it? how portable will it be? what will
:threads allow me to do exactly? etc?
http://language.perl.com/misc/perlthrtut.html
http://www.perl.com/CPAN-local/doc/manual/html/lib/Thread.html
http://www.perl.com/CPAN-local/doc/manual/html/READMEs/README.threads
http://www.perl.com/CPAN-local/doc/manual/html/lib/Thread/index.html
:I'm working on a problem that seems might
:be well easily solved by threads, if I
:understand what threads will be able to do.
Multitasking involves the computer doing more than one thing at the
same time. You can produce this situation in a variety of ways,
but they all amount to the same thing: multiple executution
contexts (PCs, SPs, & other registers) with some degree of sharing.
When you use
$kid = open(CHILD, "cmd args |");
your begotten child process shares a few file descriptors, umasks,
process group, and credentials with the original process. In fact,
nearly everything is shared. Only text, data, pid, and register
set vary.
When you use
$kid = open(MYSELF, "|-");
or
$kid = fork();
You end up sharing a bit more -- the backing store text is now the same,
but data, pid, and register set are distinct. You can open particular
communications mechanisms between the entities, such as pipes and
shared memory, but the default on data space is separate but equal.
Text pages are still shared.
People have been using fork() to write multithreaded (read: multitasking)
applications on Unix for about twenty-five years. It is a simple and
powerful model that has withstood the test of time. It is also highly
optimized, using such cleverness as copy-on-write for the data and
making use of special machine hardware designed to facilitate
context switches and page table manipulations.
Another scenario is the so-called "light-weight process". Various
implementations have taken different approaches to these. One that stands
out as different from many of the current crowd was the Convex C-series,
where FORK and JOIN were hardware instructions to create a new execution
thread without any operating system intervention whatsoever. This was
beneficial in cases where you in effect wanted highly parallizable
vector processing distributed across several CPUs where everything else
was shared. Each thread had separate thread registers, and the operating
system could consult special thread state accumulators when the whole
process ended. This tightly-knit relationship between the hardware
designers, operating system designers, and compiler designers produced
some intriguing possibilities not seen on commodity systems.
The typical use of the word "thread" now has varied greatly from its
original use, which was essentially synonymous with a fork()d process.
(And these new light-weight processes aren't always particularly light in
weight, either.) I assume you are using "thread" in the vernacular,
which most often seem to mean to create a new context where everything
is shared just as in a fork, except this time, all data space will also
be jointly accessible.
In short, with fork(), data space is protected unless you say otherwise
(such as with IPC::Shareable) whereas with Thread::->new, it's an
uncontrolled free-for-all. I can certainly see why you might wish to
have several active PCs running concurrently, but I am dubious that you
have an application for which uncontrolled, unmediated sharing amongst
these threads would be a natural solution not easily accomplishable
using the protected threads you get when you fork.
Prisoners of Microsoft tend to leap to solutions that involve
(data-)unprotected threads rather than those that involve (data-)protected
ones. This is the wrong thing to do. But they do it because an
efficient implementation requires a sound underlying theorectical model,
and Microsoft has never shown itself adept at operating systems design.
Linux protected threads (read: "processes") context-switch many times
faster on the same hardware than do Microsoft's unprotected ones (read:
"threads").
This old statement of mine is applicable in many contexts, including
the current one:
"In short, just as the Multics mentality of careful access controls
shows up throughout Unix, the cretinous CP/M mentality of uncontrolled
havoc shows up in DOS and all its mutant children." --tchrist
I'll finish up by including an interesting article that turned up in
a thread on comp.unix.programmer. There's a good bit of noise there,
but also some interesting technical data as well.
Date: 5 Jun 1999 14:34:23 -0700
From: torek@elf.bsdi.com (Chris Torek)
Subject: Re: Why fork?
Organization: none of the above
Newsgroups: comp.unix.programmer
In article <3758CA13.C26902E9@yahoo.com> G. Sumner Hayes
<sjhalpar@yahoo.com> wrote:
>[newsgroups altered as this has turned from flamewar into actual
>interesting discussion]
Indeed. :-)
>Yes. The fundamental point I was trying to make was that processes
>vs. threads is an issue of sharing memory on Unix, whereas on
>Windows there's a much more limited view of processes and the
>programmer is forced to use threads everywhere to get asynchronicity.
Yes. There is another way to view the issue, which I will get to
in a moment...
>Questions: Is fork() a wrapper around rfork() on FreeBSD? Is rfork()
>used for anything else? On Linux, vfork(), fork(), and
>pthread_create() are essentially just wrappers around clone, though
>they may be kernel-space wrappers for backwards compatibility. On
>Plan 9, rfork() is [the bottom-level call] ...
I cannot speak for other BSDs, but in BSD/OS 4.0, the model (the
code is not yet fully implemented) is that the sfork() call --
essentially the same as Plan 9's rfork() and Linux's clone() --
is the "one true" process creator. (Process 0, which forks init
and does other similar work during bootstrapping, is never really
"created": it exists in the /bsd image as loaded, modulo some
hookups needed at boot time.) There are compatibility routines,
as in any other system-with-historical-baggage, of course.
Putting aside the fundamental misunderstanding that "Ed@eds.net"
apparently had when he started trol-- er, I mean began this
discussion, :-) one way to view the whole idea is this. Note that
the terminology differs from that used when describing traditional
Unix systems.
- There is no such thing as a "process", there is just a "thread".
Here a "thread" is really just an ID, some optionally-shared
resources like memory and files, and maybe a kernel stack or
some such -- pretty much the same thing as a Unix "process".
- "Fork" just creates a new thread; everything is shared. [Note
that the new thread *does* need a way to know that it is in fact
the new one. How this is achieved is not particularly important
in terms of the model.]
- Any thread can request that some of its currently-shared
resources can become "unshared" (have a private copy made, so
that changes to them will not change someone else's copy).
[In Plan 9, Linux, and the various BSDs, these operations are
rolled into the argument to [rs]fork/clone; logically, they
should probably be separate. One can make efficiency
arguments, but see below.]
In addition:
- Any thread can wipe itself out and run some other executable
image instead (Unix "exec"). This wipes out any parts of memory
not marked "preserve across exec"[%], partly just to match
tradition, partly for ease of implementation, and partly for
security when executing setuid binaries. (In other words, it
does not *have* to be done this way. Given that current hardware
tends to implement binaries that tend not to be entirely
position-independent, we make concessions to efficiency here.
We say: "We could not figure out how to make the old image
hang around while the new image is loaded, and then give the
old image a chance to remove itself if that is what it intended.
So even though it looks like this action is made of a bunch of
simpler atomic actions, we could not figure out a nice way to
break it down.")
[% Some systems have no way to mark any such sections, in which
case *all* memory "goes away" on exec. This is why exec takes
argv and envp: to pass *some* data across the operation. "Leave
memory region R" alone would suffice for the same purpose, and
could be more efficient -- perhaps substantially so.]
Now, one can argue that "make a thread-copy and immediately exec",
which is the pair of primitives that emulates other OS's "create
new process running program P" operation, ought to be less efficient
than simply having a "create new process running program P" operation
(whether that is spelled spawn() or CreateProcess() or SYS$CREPRC
or whatever -- let me use spawn() here for short). That argument
makes some sense to me. Given a thread+exec model, fundamentally,
spawn() is just "create thread, then exec". If there is any overhead
in returning to user code, then having the user code immediately
turn around and exec, all of that overhead can be eliminated.
But if you take a look at otherwise "reasonably comparable" systems
that *do* offer "spawn" instead of fork+exec, something strange
happens. The overhead for processes in those systems turns out to
be *greater* than it is in the Unix-like systems. (Examples: VMS
vs 4.1BSD on a VAX; NT vs Linux on an x86.) This overhead leads
people to write "all in one" packages on the "spawn" systems (e.g.,
the directory lister is usually built into the user interface),
while the relative lack of overhead in the fork+exec systems leads
people to write smaller "tool" programs (the directory lister is
usually a separate program, and hence works with pipes and "wc"
word counters and "lpr" printer spooling and so on[%]). Perhaps
the people who wrote the spawn() systems were just not as good as
the people who wrote the fork+exec systems, but in any case, it
seems odd.
[%] A friend of mine suggests that you try "telling your mom" (or
any suitable non-computer-geek type) how to print out a listing
of files in some particular directory. On Unix systems: run
"ls -l | lpr".
Now for many side points, even if one of them was the main point
of the original article. First, removing all the biasing wording:
>Seems that a [model] where processes are independent of the creating
>process would be preferable to the parent-child [model imposed by] fork()
There are two reasons for having a parent/child relationship in
fork().
First, we need to distinguish between the original thread (process)
and the new thread (process). We can arbitrarily label the original
the "parent" and the new clone the "child". Or we could label them
"old" and "new", or "Fred" and "Barney", or whatever, but "parent"
and "child" works.
Second, any time any program runs any other program, it *might*
care whether that other program succeeds. If there is *no*
relationship between old and new, as suggested above, there is also
no way for the creator to get information on the createe. So there
must be *some* relationship: even if it is not a tree-structured
parent/child thing, at the very least there is a "creator/createe"
relationship, from the very fact that one process spawned the other.
Using a parent/child relationship, and tying it to the return value
from fork() (the thread/process id), is probably the simplest way
of expressing this. Even when you are not doing cloning -- even
when the only call you have is spawn() -- there is still a "creator"
(spawner) and "createe" (spawnee), and those remain "parent" and
"child", whether or not the OS tracks it.
>Isn't it more natural to think of a ProcessManager creating and
>managing processes?
"Natural" is one of those "marketing" type words that people use
to sell one shampoo vs another (ours contains 2,4-di-poly-... so
ours is More Natural!). But if you want to have a ProcessManager
do the creating, you can code that yourself on any modern Unix
system. Just write a program that listens for IPC requests to
create new processes. Run it once, then send those IPC requests.
The listening program is your ProcessManager and the IPC requests
invoke it.
Problem solved. Next? :-)
>You know my stance. That there is a goodness of fit (for me intuitively)
>with some kind of manager/process-creator facility (what specific form?
>hmmm...) and a poor fit with the existing parent-child/hierarchial
>"design".
If you like the taste of ice cream more than that of vegetables,
nothing anyone can say about the health qualities of either is
going to change your mind about which tastes better.
In some systems, there are definite "right" vs "wrong" answers.
"Everyone knows" that objects are naturally at rest -- if I roll
a baseball on the ground, it always stops rolling eventually --
but in physics, Aristotle was wrong; Newton supplied a "righter"
model. In this case, however, you have set up a system in which
only you can possibly be right: "By `right' I mean something fits
my intuition. A process manager fits my intuition, so any other
model is wrong." There is nothing to prove or disprove here; you
are letting your intuition dictate the answer, and your intuition
is yours alone.
>You see, I'm seeking to either verify _or_ nullify my premise--
>I'm not here just to argue, but rather seeking answer.
If so, you will have to come up with more objective criteria.
Someone else remarked on the "intuitive" problem:
In article <7j8spj$hjm@teal.csn.net> bediger@csn.net wrote:
>> Just a tip about arguing your case: have a clear definition of "intuitive",
>> because "intuitive" possesses a lot of semantic baggage for most people.
>I know it does. But I think they can handle it even if it puts them out
>of their normal modes a bit. Perhaps better in the above would be:
>"intuitive correctness of design"
(This sounds like a circular definition: "intuitive" means
"possesses intuitive correctness"?)
>or just "high level of appropriateness of the design"
This is still highly subjective: appropriate for what purpose?
>or "exhibiting correctness".
Here we could be objective. Correct in what regard? (Note
Aristotelian vs Newtonian physics above, and note that even Newton
was wrong because he did not take relativisitic effects into account.
Yet, for playing baseball, Aristotle's rules work best.)
>Design is creative, hence difficult, for more analytical minds.
(Flamebait. I would just delete it, but I need it for the next
sentence.)
>But all kinds of fuzzy things apply to it when elegance is being
>sought. (Oops.. I just got "fuzzy" again, I know).
You certainly did.
>But I'm the one who asked the question. You're the experts/consultants
>supposed to convince me. I'm not really trying to convince you, but
>rather challenging you to think about it and thereby soliciting your
>expert opinions--if you can do that with open minds with your design hats
>on. Forget about how it is, how should it be? Actually, I want YOU to
>tell me why "my way" might be better.
Better for what?
And:
>You tell me. I think of a process as a running program, an
>instantiation of a .exe.
This is not a good mental model for Unix systems, and indeed, not
a good mental model for many other non-Unix-like systems. To stick
with traditional Unix systems (where fork() is "create new kernel
thread, and immediately unshare all user memory"), a "process" is
made up of:
- an identifier (Process ID or "pid");
- an address space (which might map to a .exe, or might not;
the exec() call always creates such a mapping, but once exec'ed,
a process can generate and/or load new code and data [a la a "DLL"
in Microsoft-ese], and/or toss out its existing code and data,
as long it is careful);
- file descriptors (references to open files/pipes/IPC);
- credentials (~= privileges);
- resource limits;
- any other things I cannot think of off the top of my head.
Any process can change or rearrange any of these except its PID:
the PID is the outside world's "true name" for the process. (The
kernel might use a data pointer inside, if that seems more efficient
and/or appropriate, but the outside-world name is the PID.)
[bediger again]
>> Beyond that, you seem to have missed the point of seperating fork()
>> from exec(). A programmer can insert *arbitrary* code between the
>> two.
[Mr Ed]
>The complexity just keeps growing. I thought it was just fork(). Now
>there is fork(), exec(), system(), clone()...? What does the _OS_ really
>need? Can we get out of user land and get back to a more primitive OS
>land?
(That first sentence is more flamebait. Probably should just delete
it too. Oh well.)
At the OS level, there is only fork() and exec(); system() is a C
library (non-OS-level) thing. Clone() is just fork() spelled
sideways, and the sideways spelling is just to work around the fact
that, historically, fork() implies "copy (do not share) the
resources", which tends to be slow. (Copy-on-write helps a lot,
but not so much that people are not still drawn to some other
mechanism, whether it is the limited vfork() or the flexible
sfork()/rfork()/clone(), to avoid the copy altogether.) If you
prefer, fork() is just clone() spelled sideways; as noted way at
the top, the true primitive is "make a new thread with everything
shared".
Now, once you have made the new, all-shared thread, you can do this
in the "new" thread (as a shell might, to do "ls | wc"):
1 split off the file descriptors
2 create a pipe
3 make another new, all-shared thread
[new thread only, again]
3a split off the file descriptors
3b close the read side of the pipe
3c move the write side of the pipe to STDOUT_FILENO
3d exec "/bin/ls"
[NOTREACHED]
4 close the write side of the pipe
5 move the read side of the pipe to STDIN_FILENO
6 exec "/usr/bin/wc"
The "split off the file descriptors" steps are required so that
the new thread does not change or close the old thread's (shared)
descriptors, which in step (2) would make the pipe available to
the shell itself (the shell does not want it), and in step (3b)
would remove "wc"'s access to the read side of the pipe (which
would be disastrous).
(Since rfork/clone take an argument, steps 1 and 3a are actually
implicit, via "pid = xyzzyfork(SHARE_ALL_BUT_DESCRIPTORS)". That
means the process above is actually 8 steps long -- 9 if you add
in the initial fork.)
Note that a parent/child relationship occurs between "ls" and "wc"
here, even though neither program wants it. This is not a *problem*,
but it has no advantage either; it is just a side effect of the
order of user-level manipulations involved in connecting the output
of "ls" to the input of "wc". If the shell wants to be the parent
of both ls and wc, the "make a pipe" step has to occur earlier and
the sequences needs to be slightly different. (In fact, old versions
of the Bourne shell used the above sequence, while modern shells
*do* create the pipe earlier and remain the parent of each process
in the pipeline.)
>Perhaps an NT expert could offer the NT design (is that what I'm
>after? Trust me, I'll know it when I see it. :) ).
The "traditional spawn()" model looks like this:
1 create a pipe
2 move the current STDOUT_FILENO out of the way
3 move the write side of the pipe to STDOUT_FILENO
4 spawn "/bin/ls"
5 close the write side of the pipe
6 move the current STDIN_FILENO out of the way
7 move the read side of the pipe to STDIN_FILENO
8 spawn "/usr/bin/wc"
9 close the read side of the pipe
10 move the saved STDIN_FILENO back
11 move the saved STDOUT_FILENO back
In other words, it takes 11 steps, not 9, with a "spawn" model.
Even though the fork and exec steps are combined (saving one step
per fork+exec pair on the Unix shell side), the number of steps
does not go down. The reason is that the spawner must do all the
manipulation up front: there is no chance to change things around
between the "create new process" step and the "take flying leap
into new object file" step.
>Can someone draw the relationships of UNIX process management
There is really very little to draw. Whoever calls fork() is a
parent. The clone copy is a child. If a program with PID 1001
executes this C code:
/* NB: exit() is a C library routine; _exit is the OS entry point */
pid1 = fork();
if (pid1 == 0) {
/* Remember that fork() returns 0 in the clone, */
/* so this is the child process. */
pid2 = fork();
if (pid2 == 0) {
task3();
_exit(0);
}
task2();
_exit(0);
}
task1();
_exit(0);
and the new process/thread/whatever-you-want-to-call-it ID at the
first "fork" is 1002, and the new ID at the second is "1003", then
the relationship is (where "x --> y" denotes "parent --> child"):
1001 --> 1002 --> 1003
Note that PID 1002 is both a parent and a child: it is the child
of 1001, and the parent of 1003. Process 1001 will run the code in
task1(), 1002 will run the code in task2(), and 1003 will run the
code in task3().
Note that the code for task1, task2, and task3 is entirely arbitrary.
It can all be in the same program, or some of them can fork and/or
exec.
If we change the C code to read:
pid_0 = fork();
pid_1 = fork();
if (pid_0)
if (pid_1)
task00();
else
task01();
else
if (pid_1)
task10();
else
task11();
_exit(0);
and again start with pid 1001, we get a new set of relationships.
Assume we have two or more CPUs in an SMP box (or we simulate it
closely enough). The first thing that happens is that the first
fork() makes a copy of 1001, giving it PID 1002. The variable
pid_0 gets set to 1002 (nonzero) in the parent (pid 1001) and 0
(false) in the child (pid 1002). Diagrammatically:
1001 --> 1002
and 1001 has "pid_0" set to 1002. (This is possible because each
one has its own private copy of the variable "pid_0" -- we used a
copy-on-write kind of fork() here, so each process has its own
private stack.)
Next, 1001 runs on one cpu, and 1002 runs on another CPU, and each
one calls fork(). That 1001 becomes a parent yet again, with pid
1003 or 1004 as its new child; 1002 also becomes a parent, with
1004 or 1003 as its new child (it gets whichever one 1001 did not
get -- the two CPUs are racing to see who can get a new identifier
first, and assuming the SMP system is written correctly, one of
the two wins the race and gets the lower number). Without loss of
generality, assume 1001 gets 1003, and 1002 gets 1004. Now we
have:
1001 --> 1002 --> 1004
--> 1003
Processes 1001 and 1003 both have "pid_0" set to 1002 (because it
was set to 1002 before the clone operation; it has not changed).
Processes 1002 and 1004 both have it set to 0 (for the same reason).
What distinguishes 1001 from 1003, aside from their PIDs, is that
1001 has pid_1 set to 1003, and 1003 has it set to 0. Likewise,
what tells 1002 and 1004 apart is that 1002 has pid_1 set to 1004,
and 1004 has it set to 0.
Now each process tests its copy of "pid_0" and "pid_1", and 1001
executes task00(), 1002 executes task10(), 1003 executes task01(),
and 1004 executes task11().
Again, each of these "task" functions can do whatever it likes,
including more fork()s or an exec().
If you have some number-crunching to do, and N processors, you
can fork N times and divide the work up that way. You do have to
be careful not to write code like:
pid_t pids[N];
for (i = 0; i < N; i++)
pids[i] = fork();
/* now inspect pids[i] */
since that produces 2**N processes, not N processes (although
if you try that, you will probably run into a resource limit
first).
By the way, I think it is worth adding that Unix (or Ken Thompson)
did not invent fork. I believe he attributed it to the OS on the
SDS/Xerox Sigma.
In summary (since this IS awfully long): I think there is no way
to judge whether a fork+exec design is "better" or "worse" than
a "spawn" design without some particular criteria for "better-ness".
I *can*, however, say with certainty that a fork+exec system
allows code like this:
for (i = 1; i < N; i++)
if (fork() == 0)
do_subtask(i);
do_subtask(0);
that is generally difficult and/or expensive to do on "spawn-only"
systems. I can also say that, historically, Unix systems and their
clones have had lighter-weight processes than other systems, so
that the cost of doing all that forking is often (though not always,
and I think some say "not often enough") negligible.
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc
El Cerrito, CA Domain: torek@bsdi.com +1 510 234 3167
http://claw.bsdi.com/torek/ (not always up) I report spam to abuse@.
--
: The ksh scripts do not have a problem with it.
That's because ksh doesn't much mind opening up security holes. The
absence of taint checks is not exactly a feature.
Larry Wall in <1994Dec15.013044.16127@netlabs.com>
------------------------------
Date: Mon, 14 Jun 1999 12:52:47 -0400
From: Greg Bartels <gbartels@xli.com>
Subject: Re: a thread on threads
Message-Id: <3765335F.B15E5F67@xli.com>
Thanks,
Marcel Grunauer wrote:
>
> On Mon, 14 Jun 1999 10:44:19 -0400, Greg Bartels <gbartels@xli.com>
> wrote:
>
> >Can anyone give me the lowdown on threading in perl?
> >last perl installation I did prompted me as to
> >whether I wanted to use threads or not, and that
> >threading was still experimental/not stable.
> >this was about a month or so ago.
> >
> >is there an URL I could go read up on the
> >current status of threads? who's working on
> >it? how portable will it be? what will
> >threads allow me to do exactly? etc?
> >
> >I'm working on a problem that seems might
> >be well easily solved by threads, if I
> >understand what threads will be able to do.
> >
> >Greg
>
> Well, for a start there's Dan Sugalski's perlthrtut, available as part
> of the new documentation for 5.005_57, or on
> http://language.perl.com/misc/perlthrtut.html.
>
> Also check the Thread.pm documentation.
>
> There is also an article on threads on
> http://www.heise.de/ix/artikel/1998/10/154/default.shtml, although
> it's in German, so it might or might not be of any use to you.
>
> Hope this is "useful" :-)
>
> Marcel
------------------------------
Date: Mon, 14 Jun 1999 17:04:13 +0100
From: Paul Bunkham <paul.bunkham@synetica.com>
Subject: Re: another href extraction question!
Message-Id: <376527FD.6D8A7F7F@synetica.com>
jpeterson@office.colt.net wrote:
>
> If you are on Win32 I surrender :-)
ActivePerl has HTML::Parser bundled (I think unless I installed it using
ppm, but that shouldn't cause a problem), and it works fine, or well
enough for this problem at least, so no need to surrender just yet...
Just thought you might like to know.
--
*****************************************
Paul Bunkham
Developer
Synetica Knowledge Technologies
*****************************************
------------------------------
Date: Mon, 14 Jun 1999 15:59:41 GMT
From: dragnovich@my-deja.com
Subject: Databases!! HELP!!
Message-Id: <7k38t5$s82$1@nnrp1.deja.com>
Hello folks Im a good perl programmer (yea right) and now I have a big
problem, I need to use any kind of DB form! but I dont know nothing abou
t Data Bases! ... so ok this are the questions (some are not for this
group but i post the same message on varius news groups)
1.- I use PERL for programming and I have 4 servers ! 2 Windows NT IIS3,
and 2 FreeBSD.
2.- I need some DB routines that can be used with perl in both flavors
of OS. You know names?? say them! (if have links! super!)
3.- I dont need a ultra fast mannagers, many users or things like that!
I just want to start using DB with perl for Unix and NT.
Well I hope you can send me some examples and/or links please!! =-)
Regars
------------------------
Juan Carlos Lopez
QDesigns President & CEO
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Mon, 14 Jun 1999 12:59:54 -0400
From: Craig Ciquera <craig@mathworks.com>
Subject: Re: Databases!! HELP!!
Message-Id: <3765350A.FDB431B9@mathworks.com>
DBI and MySQL:
http://www.symbolstone.org/technology/perl/DBI/doc/tpj5/index.html
and
http://www.mysql.com
MySQL is a free DB and its pretty awesome.
Craig
dragnovich@my-deja.com wrote:
> Hello folks Im a good perl programmer (yea right) and now I have a big
> problem, I need to use any kind of DB form! but I dont know nothing abou
> t Data Bases! ... so ok this are the questions (some are not for this
> group but i post the same message on varius news groups)
>
> 1.- I use PERL for programming and I have 4 servers ! 2 Windows NT IIS3,
> and 2 FreeBSD.
> 2.- I need some DB routines that can be used with perl in both flavors
> of OS. You know names?? say them! (if have links! super!)
> 3.- I dont need a ultra fast mannagers, many users or things like that!
> I just want to start using DB with perl for Unix and NT.
>
> Well I hope you can send me some examples and/or links please!! =-)
> Regars
>
> ------------------------
> Juan Carlos Lopez
> QDesigns President & CEO
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
------------------------------
Date: 15 Jun 1999 07:32:58 GMT
From: hasant@trabas.co.id (Hasanuddin Tamir)
Subject: Re: DIFF BETWEEN PERL & CGI
Message-Id: <slrn7maapu.5r1.hasant@borg.intern.trabas.co.id>
On Sun, 13 Jun 1999 12:17:31 -0700, Tom Phoenix <rootbeer@redcat.com> wrote:
> On Sun, 13 Jun 1999 dharmin98@my-deja.com wrote:
>
[snip]
> > whats the difference between Perl & CGI
[snip]
(Well, I missed the original post so I put it on TomP's)
CGI is the duct, Perl is the tape.
(heck I like the article so much).
HTH,
--
-hasan-
uhm, no more sig(h)
------------------------------
Date: Mon, 14 Jun 1999 11:31:47 -0400
From: Deamon George Scapin <dscapin@harris.com>
Subject: Re: dimensions of a jpg file
Message-Id: <37652060.7D393332@harris.com>
--------------297C14B8E7F28C403B7962B0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Jonathan Stowe wrote:
> It looks like you have failed to install Image::Size correctly - You need
> to have the directory c:\perl\lib\site\image containing the files from
> the distribution - I am pretty certain there is no PPD file for easy
> installation from Activestate and I am also pretty sure there are no
> XS componenents to worry about.
I have all the files in that sub-directory, /perl/lib/image/size... Now I get the
following error:
C:\Program Files\sambar42\cgi-bin>perl image.pl
Can't locate auto/Image/Size/autosplit.ix in @INC (@INC contains: C:\PERL\lib\si
te C:\PERL\lib c:\perl\lib c:\perl\lib\site c:\perl\lib\site .) at C:\PERL\lib/A
utoLoader.pm line 84.
at C:\PERL\lib/Image/Size.pm line 211
What is this autosplit.ix?
> None of this can be done in a CGI program - if you need to find out more
> you might want to ask in some group in the comp.infosystems.www.* hierarchy.
>
What I am trying to do is to fit an image that is bigger than the browser into the
browser window. The way I thought I would do that is by getting the dimensions for
the screen and the dimensions for the picture, then fit the image into the window.
That is the reason I need to use the image size module. But I am having trouble
using the module.
--------------297C14B8E7F28C403B7962B0
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<HTML>
<P>Jonathan Stowe wrote:
<BLOCKQUOTE TYPE=CITE>It looks like you have failed to install Image::Size
correctly - You need
<BR>to have the directory c:\perl\lib\site\image containing the files from
<BR>the distribution - I am pretty certain there is no PPD file for easy
<BR>installation from Activestate and I am also pretty sure there are no
<BR>XS componenents to worry about.</BLOCKQUOTE>
I have all the files in that sub-directory, /perl/lib/image/size... Now
I get the following error:
<P><FONT FACE="Courier New,Courier"><FONT SIZE=-2>C:\Program Files\sambar42\cgi-bin>perl
image.pl</FONT></FONT>
<BR><FONT FACE="Courier New,Courier"><FONT SIZE=-2>Can't locate auto/Image/Size/autosplit.ix
in @INC (@INC contains: C:\PERL\lib\si</FONT></FONT>
<BR><FONT FACE="Courier New,Courier"><FONT SIZE=-2>te C:\PERL\lib c:\perl\lib
c:\perl\lib\site c:\perl\lib\site .) at C:\PERL\lib/A</FONT></FONT>
<BR><FONT FACE="Courier New,Courier"><FONT SIZE=-2>utoLoader.pm line 84.</FONT></FONT>
<BR><FONT FACE="Courier New,Courier"><FONT SIZE=-2> at C:\PERL\lib/Image/Size.pm
line 211</FONT></FONT>
<P>What is this autosplit.ix?
<BR>
<BLOCKQUOTE TYPE=CITE>None of this can be done in a CGI program - if you
need to find out more
<BR>you might want to ask in some group in the comp.infosystems.www.* hierarchy.
<BR> </BLOCKQUOTE>
What I am trying to do is to fit an image that is bigger than the browser
into the browser window. The way I thought I would do that is by
getting the dimensions for the screen and the dimensions for the picture,
then fit the image into the window. That is the reason I need to
use the image size module. But I am having trouble using the module.</HTML>
--------------297C14B8E7F28C403B7962B0--
------------------------------
Date: Mon, 14 Jun 1999 11:38:06 -0400
From: Deamon George Scapin <dscapin@harris.com>
Subject: Re: dimensions of a jpg file
Message-Id: <376521DE.8CF90453@harris.com>
> But this is in the ActiveState repository. He only has to type:
>
> ppm install Image-Size
>
> to get it and its associated parts.
>
I don't have ppm, is that perls module installer? I'll look for it on the web and
download it.
> It sounds to me like he's trying to do the wrong thing in his
> layout. Pixels instead of percents, perhaps. The GUIs like
> Front Page conveniently conceal the fact the HTML is *not*
> page layout [in the FrameMaker sense]. Oh well...
All I'm trying to do is to fit a very large picture (jpg) into the browser window
so that the user doesn't need to scroll in order to view the picture. So I
thought I'd get dimensions of the picture and the browser, then force the picture
to fit into the window.
------------------------------
Date: Mon, 14 Jun 1999 13:13:51 -0400
From: Deamon George Scapin <dscapin@harris.com>
Subject: Re: dimensions of a jpg file
Message-Id: <3765384E.D2D21D73@harris.com>
> But this is in the ActiveState repository. He only has to type:
>
> ppm install Image-Size
>
Okay, I downloaded a newer version of perl which had ppm. I installed the module
and can use it when I compile from a dos prompt. But when I use Samba42 server
software to simulte my page online, I can't call the page from netscape. It
returns a document with no data meaning that an error occured, when I take out the
use statement, the cgi program is called fine from netscape.
------------------------------
Date: Mon, 14 Jun 1999 16:31:08 GMT
From: bart.lateur@skynet.be (Bart Lateur)
Subject: Re: Dynamic Regular Expression
Message-Id: <37652d28.1029019@news.skynet.be>
Tom Christiansen wrote:
> Christoph Schmitz <cschmitz@stud.informatik.uni-trier.de> writes:
>: $subtext = 'sub { $_ = shift; return (/a/ && /b/); }'
>: ^^^ insert your stuff here
>: $coderef = eval $subtext;
>Per usual, I see no reason for an eval().
It is necessary, if this is modified so that the "code" string in
$subtext is generated dynamically from the user query.
Bart.
------------------------------
Date: 14 Jun 1999 11:49:56 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Dynamic Regular Expression
Message-Id: <376540c4@cs.colorado.edu>
[courtesy cc of this posting mailed to cited author]
In comp.lang.perl.misc,
bart.lateur@skynet.be (Bart Lateur) writes:
:>Per usual, I see no reason for an eval().
:It is necessary, if this is modified so that the "code" string in
:$subtext is generated dynamically from the user query.
So what? That's what qr// is for. :-)
--tom
--
You are the sponsor for the account andrew (Andrew Hume).
------------------------------
Date: 12 Dec 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Special: Digest Administrivia (Last modified: 12 Dec 98)
Message-Id: <null>
Administrivia:
Well, after 6 months, here's the answer to the quiz: what do we do about
comp.lang.perl.moderated. Answer: nothing.
]From: Russ Allbery <rra@stanford.edu>
]Date: 21 Sep 1998 19:53:43 -0700
]Subject: comp.lang.perl.moderated available via e-mail
]
]It is possible to subscribe to comp.lang.perl.moderated as a mailing list.
]To do so, send mail to majordomo@eyrie.org with "subscribe clpm" in the
]body. Majordomo will then send you instructions on how to confirm your
]subscription. This is provided as a general service for those people who
]cannot receive the newsgroup for whatever reason or who just prefer to
]receive messages via e-mail.
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V8 Issue 5989
**************************************
