* Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page)
Everybody check out the LOTR winamp skin I made here.
remember earl from nexabit?
by
Anonymous Coward
·
· Score: -1, Troll
second post!
This ever-popular classic is still making the sweetest memories...for over 35 years and counting! Your child will have real baking fun--make cakes, cookies and so much more! Oven comes with 4 different mixes, 2 baking pans, 2 utensils, pan pusher, 2 trays to warm toppings, tray cover and recipes/instructions.
Re:remember earl from nexabit?
by
I.T.R.A.R.K.
·
· Score: -1, Offtopic
Does it come with the leather bound gimp?
And please tell me the ball gag isn't sold separately.
- I throw rocks at retarded kids
--
"Adequacy.org: Where congenital stupidity is not an option, but a requirement."
Re:remember earl from nexabit?
by
buttfucker2000
·
· Score: -1
Personally, I think it's not only quite funny, but a great way to get people involved and interested in perl who might have only glanced upon perl before.
hmm, i feel just the opposite. a very stupid way to make people realize that perl is made by a bunch of imbeciles who glorify stupidity, cuteness, and code unreadability. is anyone else seriously turned off by perl peoples' stupid hijinx and see the project as being run by people who value puns far more than quality?
Not often is this true, but this article be funny. I mean really funny. And really, the only thing funnier than perl is COLBALT.
a thread on threads
by
Spootnik
·
· Score: -1, Redundant
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.
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:
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.
"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?:-)
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.
If so, you will have to come up with more objective criteria.
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.)
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.)
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.
There is really very little to draw. Whoever calls fork() is a
parent. The clone copy is a child.
Re:a thread on threads
by
magicslax
·
· Score: -1, Offtopic
Obufscated Haiku'd Perl
by
ukryule
·
· Score: 5, Funny
So to sum up this article, if you add this at the top of your Perl programs:
use Symbol::Approx::Sub;
use Coy;
Then not only will your Perl be even less decipherable than normal Perl code (wow!), but the errors you get from it will be hidden in lines of poetry! No self-respecting programmer would have it any other way...
Now, it's back to debugging my program for me:
-----
Two old men encounter
beside a pond. A swallow
flying. Two trout.
-----
Lao Tse's commentary...
Execution of./new.pl aborted due to compilation errors.
("The Way of Mysterious Compiler": line ???)
Decoded Geekcode from the article
by
Nevrar
·
· Score: 3, Informative
Robot fancy ( a rememberence )
by
chemstar
·
· Score: -1, Offtopic
This reminds me of when we put our robots in the freezer with the program:
10: print "BRRRRRRRRR"
20: GOTO 10
Amiga
by
Anonymous Coward
·
· Score: -1, Offtopic
Wasn't there supposed to be some big announcement from Amiga Inc. today? What happened to that?
Re:Amiga
by
Anonymous Coward
·
· Score: -1, Offtopic
Dunno. My impression is that their Vice President of Development, Fleecy Moss, thought he was some kind of hotshot software designer, but in reality he is a marketing guy without much understanding, it would seem, of the realities of software development. He described lots of really cool shit, much of it bordering on science fiction, that they had no chance of implementing with their resources.
"First Anal Felchings" comments are one of those odd little memetic hiccups that come out of nowhere and run amok. Basically, people with altogether far too much spare time sit and reload Slashdot, hoping that they will get the "First Anal Felching" in a discussion. This is one of those things that the moderation system was designed to fuck hard, and for the most part, it works. "First Anal Felching" comments usually get moderated up as +5 funny almost instantly. Also, I would like to say that I am the first male to have 4 cocks shoved up his ass simultaneously.
You didn't read the article. There are several Perl packages available that are related to LoTR: Date::Discordian, to print Discordian dates, Date::Tolkien::Shire, which does a 'today in history' for LoTR. Others are mentioned, but those are the ones specific to LoTR.
-- I think...I think it's in my basement. Let me go upstairs and check. -M.C. Escher (1898-1972)
While I think its probably irrelevant to point out that I've read the article, I don't suppose you could remind me of the link between Date::Discordian (something clearly inspired by the brilliance of the Illuminatus! trilogy) and LoTR? I know that Leviathon references LoTR as well, but is there something else?
I remember when I used to use Matlab, there was a funtion called "Why". It used to spit out these silly answers. It somehow made using Matlab slightly less tedious.
This is just like all the hidden easter eggs in programs written by most programmers. (The built in screen saver in some versions of Word does not count.)
Hey, I was fine with it at the score it was when I posted it.
--
I see even classic Slashdot is now pretty much unusable on dial up anymore.
Totally misread the headline
by
cancrman
·
· Score: 3, Funny
I thought it said "The Lighter Side of CSPAN". What a strange/. topic....
-- The sole purpose of the Internet is to get porn and bomb making plans into the hands of children.
Re:Totally misread the headline
by
sprayNwipe
·
· Score: 1
Me too... I was expecting some Dick Clark-hosted blooper-reel footage of when Strom Thurmond met with some animals and kids, but with hilarious and disasterous results!
Re:Totally misread the headline
by
Anonymous Coward
·
· Score: -1, Offtopic
Just a friendly reminder: the "No +1 Bonus" checkbox is there for a reason.
Re:Totally misread the headline
by
Anonymous Coward
·
· Score: -1, Offtopic
So is the Anonymous Coward checkbox, which you've obviously figured out. Good job!
Re:Totally misread the headline
by
Spootnik
·
· Score: -1, Offtopic
Since you care so much about your all mighty karma points, why don't you go hang out with Oprah Winfrey or something. Leave us the fuck alone, biznatch!
She wore a PERL necklace
by
journalistguy
·
· Score: 1
Perhaps the author should get in touch with the wacky ophthalmologist responsible for this site and pick up a few tips on making indecipherable humor err...decipherable.
From seeing the trailer it looks like there might be a 1/2 decent movie to come out in 2001. Best I've see so far is Zoolander and that doesnt say much.
It's so on topic, I'm blinded by it. I mean, Jesus, he practically read four whole words out of the entire story. That's just a few steps short of reading the article, which is only a few steps short of actually having something useful to say about the topic! In fact, his post is so on topic and knowledgable I'm about to ejaculate in sheer awe of it!
Good Parts Version (TM)
by
PeterClark
·
· Score: 0, Redundant
It's way to late, and I should be in bed, but I thought I would c/p the relevant parts of the article for those at work tomorrow who find the site/.ed. Sorry that I didn't preserve the HTML formatting. The rest is amusing, too, so you might want to come back to it once the servers have recovered. (If you're the type of person who gets excited over perl modules, that is. The rest of you might just want to watch CSPAN.:)
:Peter
---
Moving swiftly on, we come to Date::Tolkien::Shire, a king amongst date modules. Most newspapers carry an ``on this day in history'' column -- where you find, for instance, that you were born on the same day as the man who invented chili-paste -- but no broadsheet will tell you what happened to Frodo and his valiant companions as they fought to free Middle Earth from the scourge of the Dark Lord. The undeceptively simple:
use Date::Tolkien::Shire;
print Date::Tolkien::Shire->new(time)->on_date, "\n";
outputs (well, output a few days ago):
Highday Winterfilth 30 7465
The four Hobbits arrive at the Brandywine Bridge in the dark, 1419.
What better task could there be for crontab but to run this in the wee hours and update/etc/motd for our later enjoyment. Implementing this is, as ever, left as an exercise for the interested reader.
There is a more useful side to Date::Tolkien::Shire or, at the very least, it does light the way for other modules. As well as the on_date() method it provides an overloaded interface to the dates it returns. This allows you to compare dates and times as if they were normal numbers, so that:
print 'time is '.( $date1 > $date2 ? 'later':'earlier' ).
"than time -1e6\n";
prints time is later than time -1e6, the more prosaic Date::Simple module provides a similar interface for real dates and ensures they stringify with ISO formatting.
Unfortunately, it turns out that he's like one of those annoying five-year-olds who thinks a joke gets funnier if you repeat it over and over again. He's been telling this joke for about 14 years now.
Re:I always thought...
by
Anonymous Coward
·
· Score: 0
And the fact that people bothered to use perl at all was evidence that either a) people have too much time on their hands, or b) that a lot of people are intelectually bored that they need something to complex and convoluted to keep them occupied! But hey, more power to them, those bastards stuck at a "job."
Re:I always thought...
by
Anonymous Coward
·
· Score: 0
The synchronicity machine clicked, and the name of Eris adorned his prose. The author is one of us without any doubt. Funny I followed a Perl link, being a wannabe Pythonista and all that cal, but the Discordian reference made it all blissfully clear in a very obscure manner - the usual tool of the old girl, eh? All hail Discordia!
Does it really seem like a good idea to have our computers guessing about what we mean? To be honest, they're not smart enough for me to trust them with that kind of authority quite yet. Until my computer can actually construct a useful PERL routine and explain its reasoning to me, I don't really want it guessing which one I meant by my typo...
is it any better to have Microsoft guessing (or telling) us what we want? Actually computers already tend to guess what we mean on a regular basis. That's what spell/grammar checking does.
I can't believe the article did not mention ACME::Bleach which just bleaches your program. Run it once and your code magically disappears... but still runs!
ACME::Buffy is similar, except your program is turned into a Buffy mantra that can be chanted or executed.
In fact the whole ACME name space is reserved just for silly and incredibly useful modules.
-- Look, that's why there's rules, understand? So that you think before you break 'em. (Terry Pratchett)
Re:More serious modules
by
Anonymous Coward
·
· Score: 0
It did mention this in the second paragraph:
Portions of this creative outpouring of humor often find their way onto the CPAN. There is even the special Acme::* name space set aside for these bizarre freaks so they do not interfere with the normal smooth running of that ever so special service.
So at least Acme:: was mentioned.
Re:More serious modules
by
johnhyland
·
· Score: 0
If you like ACME::Bleach, you should try ACME::Smirch. Wash all those messy alphanumerics right out of your code!
Let me get this straight...
by
Anonymous Coward
·
· Score: -1, Troll
The worst terrorist attack in recorded history occurred last month, and now we're involved in a WAR and you people have the gall to be discussing the lighter side of CPAN???? My *god*, people, GET SOME PRIORITIES!
The bodies of the thousands of innocent civilians who died (and will die) in these unprecedented events could give a good god damn about the lighter side of CPAN, your childish Lego models, your nerf toy guns and whining about the lack of a "fun" workplace, your Everquest/Diablo/D&D fixation, the latest Cowboy Bebop rerun, or any of the other ways you are "getting on with your life" (here's a hint: watching Cowboy Bebop in your jammies and eating a bowl of Shreddies is *not* "getting on with your life"). The souls of the victims are watching in horror as you people squander your finite, precious time on this earth playing video games!
And who said that quantum computers a centurys away?? You can get started on your 386 right now, courtesy of CPAN!
Also, about that eliza chatbot: there is an easier way to get started (you may have seen this in this months linux journal, non?):
$ emacs
esc
shift-X
doctor
And there you go - a psychotherapist built right into your text editor. Perfect for those times when that fscking bug makes you want to give it all up...
Anyway, next time someone complains about MS bloatware being so cheeky that they included a flight sim in a version of Excel, I shall point this out!
Re:They missed another good one
by
scrutty
·
· Score: 1
$ emacs
esc
shift-X
doctor
you don't need the Shift. Just esc x doc (tab to autocomplete) will do.
Or use your meta key in place of esc, if you have one. Often mapped to L-alt on Linux distros.
-- --
Oh Well
Re:They missed another good one
by
Marcus+Brody
·
· Score: 1
thanks.
i'm actually a vi man myself, which explains my long route.
anyways, we dont want to get into that discussion do we....
must get round to learning emacs one of these days (im a nix begginer, see...), but vi suits my needs for now.
Marcus
Re:They missed another good one
by
susi
·
· Score: 1
And when the doctor has started, there's an extremely useful command in the namespace: M-x doctor-strangelove
On first glance....
by
Anonymous Coward
·
· Score: 2, Funny
I thought that said "The Lighter Side of CSPAN." Boy, was I disappointed when I clicked on that!
Of *course* Perl is funny!
by
Linux+Freak
·
· Score: 2
I've known for a long time that Perl is a funny language. After all, its creator, "Larry Wall", definitely has a sense of humour.
...you might be better off investigating the Time::Human module by Simon Cozens. This creates person-friendly descriptions of a time, transforming the excessively precise 00:23:12.00 into a positively laid-back ``coming up to 25 past midnight.''
I've surfed around CPAN, google, and Simon Cozens' home page but can't find this module. Can anybody point me to it?
Slashdot Mirror
this blather added to avoid lameness filtering.
* Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page)
second post!
This ever-popular classic is still making the sweetest memories...for over 35 years and counting! Your child will have real baking fun--make cakes, cookies and so much more! Oven comes with 4 different mixes, 2 baking pans, 2 utensils, pan pusher, 2 trays to warm toppings, tray cover and recipes/instructions.
Personally, I think it's not only quite funny, but a great way to get people involved and interested in perl who might have only glanced upon perl before.
--NovaScorpio
Matt
ha ha ha that is funny! yes it is!
Go fuck yourself.
Not often is this true, but this article be funny. I mean really funny. And really, the only thing funnier than perl is COLBALT.
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.
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
Putting aside the fundamental misunderstanding that "Ed@eds.net" apparently had when he started trol-- er, I mean began this discussion,
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.
Now for many side points, even if one of them was the main point of the original article. First, removing all the biasing wording:
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.
"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?
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.
If so, you will have to come up with more objective criteria.
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.)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
- [new thread only, again]
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).2 create a pipe
3 make another new, all-shared thread
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"
(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.)
The "traditional spawn()" model looks like this:
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.
There is really very little to draw. Whoever calls fork() is a parent. The clone copy is a child.
Now, it's back to debugging my program for me:
There's a few syntax errors in that geekcode, but here's the decoded (valid) geekcode from the article
--
Nevrar
This reminds me of when we put our robots in the freezer with the program:
10: print "BRRRRRRRRR"
20: GOTO 10
Wasn't there supposed to be some big announcement from Amiga Inc. today? What happened to that?
I started to read this article, and then suddenly remembered why I think perl sucks.
"First Anal Felchings" comments are one of those odd little memetic hiccups that come out of nowhere and run amok. Basically, people with altogether far too much spare time sit and reload Slashdot, hoping that they will get the "First Anal Felching" in a discussion. This is one of those things that the moderation system was designed to fuck hard, and for the most part, it works. "First Anal Felching" comments usually get moderated up as +5 funny almost instantly. Also, I would like to say that I am the first male to have 4 cocks shoved up his ass simultaneously.
-CmdrTaco
The Slashdot Effect: A new for
WTF does that article on some CPAN modules have to do with LoTR?
I remember when I used to use Matlab, there was a funtion called "Why". It used to spit out these silly answers. It somehow made using Matlab slightly less tedious.
This is just like all the hidden easter eggs in programs written by most programmers. (The built in screen saver in some versions of Word does not count.)
I thought it said "The Lighter Side of CSPAN". What a strange /. topic....
The sole purpose of the Internet is to get porn and bomb making plans into the hands of children.
Perhaps the author should get in touch with the wacky ophthalmologist responsible for this site and pick up a few tips on making indecipherable humor err...decipherable.
[Insert the usual disclaimer here]
From seeing the trailer it looks like there might be a 1/2 decent movie to come out in 2001. Best I've see so far is Zoolander and that doesnt say much.
It's so on topic, I'm blinded by it. I mean, Jesus, he practically read four whole words out of the entire story. That's just a few steps short of reading the article, which is only a few steps short of actually having something useful to say about the topic! In fact, his post is so on topic and knowledgable I'm about to ejaculate in sheer awe of it!
It's way to late, and I should be in bed, but I thought I would c/p the relevant parts of the article for those at work tomorrow who find the site /.ed. Sorry that I didn't preserve the HTML formatting. The rest is amusing, too, so you might want to come back to it once the servers have recovered. (If you're the type of person who gets excited over perl modules, that is. The rest of you might just want to watch CSPAN. :)
:Peter
/etc/motd for our later enjoyment. Implementing this is, as ever, left as an exercise for the interested reader.
---
Moving swiftly on, we come to Date::Tolkien::Shire, a king amongst date modules. Most newspapers carry an ``on this day in history'' column -- where you find, for instance, that you were born on the same day as the man who invented chili-paste -- but no broadsheet will tell you what happened to Frodo and his valiant companions as they fought to free Middle Earth from the scourge of the Dark Lord. The undeceptively simple:
use Date::Tolkien::Shire;
print Date::Tolkien::Shire->new(time)->on_date, "\n";
outputs (well, output a few days ago):
Highday Winterfilth 30 7465
The four Hobbits arrive at the Brandywine Bridge in the dark, 1419.
What better task could there be for crontab but to run this in the wee hours and update
There is a more useful side to Date::Tolkien::Shire or, at the very least, it does light the way for other modules. As well as the on_date() method it provides an overloaded interface to the dates it returns. This allows you to compare dates and times as if they were normal numbers, so that:
$date1 = Date::Tolkien::Shire->new(time);
$date2 = Date::tolkien::Shire->new(time - 1e6);
print 'time is '.( $date1 > $date2 ? 'later':'earlier' ).
"than time -1e6\n";
prints time is later than time -1e6, the more prosaic Date::Simple module provides a similar interface for real dates and ensures they stringify with ISO formatting.
...that Perl itself was evidence that Larry Wall had a sense of humor.
The synchronicity machine clicked, and the name of Eris adorned his prose. The author is one of us without any doubt. Funny I followed a Perl link, being a wannabe Pythonista and all that cal, but the Discordian reference made it all blissfully clear in a very obscure manner - the usual tool of the old girl, eh? All hail Discordia!
was this supposed to be funny?
Wow.
Does it really seem like a good idea to have our computers guessing about what we mean? To be honest, they're not smart enough for me to trust them with that kind of authority quite yet. Until my computer can actually construct a useful PERL routine and explain its reasoning to me, I don't really want it guessing which one I meant by my typo...
"Doctor who?" --The Doctor
I can't believe the article did not mention ACME::Bleach which just bleaches your program. Run it once and your code magically disappears... but still runs!
ACME::Buffy is similar, except your program is turned into a Buffy mantra that can be chanted or executed.
In fact the whole ACME name space is reserved just for silly and incredibly useful modules.
Look, that's why there's rules, understand? So that you think before you break 'em. (Terry Pratchett)
The worst terrorist attack in recorded history occurred last month, and now we're involved in a WAR and you people have the gall to be discussing the lighter side of CPAN???? My *god*, people, GET SOME PRIORITIES!
The bodies of the thousands of innocent civilians who died (and will die) in these unprecedented events could give a good god damn about the lighter side of CPAN, your childish Lego models, your nerf toy guns and whining about the lack of a "fun" workplace, your Everquest/Diablo/D&D fixation, the latest Cowboy Bebop rerun, or any of the other ways you are "getting on with your life" (here's a hint: watching Cowboy Bebop in your jammies and eating a bowl of Shreddies is *not* "getting on with your life"). The souls of the victims are watching in horror as you people squander your finite, precious time on this earth playing video games!
You people disgust me!
Quantum::Entaglement
And who said that quantum computers a centurys away?? You can get started on your 386 right now, courtesy of CPAN!
Also, about that eliza chatbot: there is an easier way to get started (you may have seen this in this months linux journal, non?):
$ emacs
esc
shift-X
doctor
And there you go - a psychotherapist built right into your text editor. Perfect for those times when that fscking bug makes you want to give it all up...
Anyway, next time someone complains about MS bloatware being so cheeky that they included a flight sim in a version of Excel, I shall point this out!
I thought that said "The Lighter Side of CSPAN." Boy, was I disappointed when I clicked on that!
I've known for a long time that Perl is a funny language. After all, its creator, "Larry Wall", definitely has a sense of humour.
The proof of this, of course, is right here, and here.
___
Cognitive Overflow
more than yo
Perl, It's my new obsession
Perl!~/\?/
Perls on the neck of your lover
'coz Perl gives you stuff to discover
Perl at the bin in my /usr
- you could be my dromedaryPerl, cos you are no luser
Perl, it's the coding with passion
cos() today it just goes with the Slashdot
'coz Perl is a lingo so scary
Perl likes its vars with the dollar
it's curled but you don't ever tell 'er, yeah I want to be your regex
I wanna doc you in latex
Perl on the screens that we key on
Perl, do I hate that one python, yeah
Escher was the first MC and Giger invented the HR department.