> I seriously doubt it. It's usually a bad idea to make anything more
> complicated than strictly needed.
>
> Multiprocessing is a lot of work, mostly because you have to control
> how information is shared between the two processes/threads. For
> example, even in a simple find and replace scr
On Tuesday, September 2, 2003, at 11:51 PM, Bryan Harris wrote:
Thanks for the info, James. Sounds like threading is still a ways
over my
head, but forking sounds interesting.
I have a perl script that does simple find-replaces within all the
files
passed to it (the key parts were written by
Thanks for the info, James. Sounds like threading is still a ways over my
head, but forking sounds interesting.
I have a perl script that does simple find-replaces within all the files
passed to it (the key parts were written by very kind people on this list,
actually). Would it be advantageou
On Friday, August 29, 2003, at 01:32 AM, Bryan Harris wrote:
Neat! Is this how "threads" are spawned? or are forked processes
different
from threads?
If this is how threads are spawned, how do big commercial apps manage
to do
multiple things at once without completely duplicating the entire
ZSDC,
I love this stuff! You explain these concepts very clearly, have you ever
considered teaching? I'm happy to keep asking questions as long as you're
willing to answer them. =)
> Servers often work this way. There's a process listening on a port but
> when someone connects, it doesn't se
Bryan Harris wrote:
The fork concept can be quite confusing at first, but it is actually
quite simple, once you get used to it. Check out the output of this
little program:
[ very interesting stuff cut out ]
Wild! Why would anyone ever use this? Why would you ever want to clone
yourself at the
> The fork concept can be quite confusing at first, but it is actually
> quite simple, once you get used to it. Check out the output of this
> little program:
[ very interesting stuff cut out ]
Wild! Why would anyone ever use this? Why would you ever want to clone
yourself at the current poin
[EMAIL PROTECTED] wrote:
Thanks for replying zsdc. The $1,$2 thing makes perfect sense now.
As for the fork/exec thing, those pages are a little over my head. I
don't understandhow process signals and pipes work.
The fork concept can be quite confusing at first, but it is actually
quite simple
>> 2. How do I set off a new process, not waiting or caring about any
>> return values?
>>
>> $myApp = "/proj/mycoolexecutable";
>> $myOptions = "-f -n2 file1 file2";
>> # execute $myApp." ".$myOptions here, and do not wait for any return
>> values
>
> See:
> perldoc -f fork
> perldoc -f exec
Bryan Harris wrote:
... which seems to work (correctly returns file_3.1.1), but I'm not sure how
the nested parenthesis are supposed to be referenced. How would I get what
was matched by the inner set? Is this the best way to do this?
Everything is captured in $1, $2, $3... in the order of openi
Two quick questions for the gurus:
1. How are nested parenthesis in a match m// backreferenced? I have a
folder full of files:
file_3.0
file_3.0.1
file_3.0.1a
file_3.0.1b
file_3.0.10
file_3.1
file_3.1.1
file_3.2a
And I want the last one without any letters in the number (not an
alpha/beta).
11 matches
Mail list logo
