fork within object constructor

[hobosalesman]

I'm trying to plan out a program and I have a couple questions (which
I've looked up but couldn't find a satisfactory answer for).

1) Is there anything inherently wrong with calling fork() within the
constructor for my object? I'm trying to make a program that works
similar to something like apache, it has a parent that creates many
children which it manages. I have a "child" class which I use to create
child objects something like:

$child = Child->new();
if ($child->(isChild)) {} else {}

The object would know if it were the child by what fork() returns.

2) The children and the parent both need some modules, like DBI, but
some are needed by one but not the other. Is there a problem putting
"use PackageX" for evrey package both processes will need or would that
be wasting resources? Should I maybe do something like:

if ($child->(isChild)) {
require "child libraries";
} else {
require "parent libraries";
}

And then "use PackageX" inside those libraries... will that have the
packages called at run time (not called if not needed) rather than at
compile time as in a normal "use X"? Or is my understanding way short
here?

3) Are there any good books out there on writing these kinds of
programs in perl? This is a web crawler search engine, but I'm
interested in the design aspects of these kinds of programs, which I
suppose aren't language specific. I'm not finding much good information
on managing persistent daemon-style programs or database design for
search engines.

 

[hobosalesman]

I'm still trying to work out the best way to do this... now I'm
wondering if I can fork() in the constructor and then exec() in it as
well, so the child would never return from the constructor it would
just end and be replaced witht he child process, then I can worry about
the child as a whoel seperate program.

?

I'm a bit new to this and I have no examples to go by.

 

[xhoster]

I'm trying to plan out a program and I have a couple questions (which
I've looked up but couldn't find a satisfactory answer for).

1) Is there anything inherently wrong with calling fork() within the
constructor for my object? I'm trying to make a program that works
similar to something like apache, it has a parent that creates many
children which it manages. I have a "child" class which I use to create
child objects something like:

$child = Child->new();
if ($child->(isChild)) {} else {}

Why would you do it this way? If you are not going to hide
the implications of the fork inside the child code, why hide the
fork itself in there?

To put it another way, you specifically asked for a new Child. Why would
you then have to ask if this new Child is really a Child?

The object would know if it were the child by what fork() returns.

2) The children and the parent both need some modules, like DBI, but
some are needed by one but not the other. Is there a problem putting
"use PackageX" for evrey package both processes will need or would that
be wasting resources?

Ordinarily there will be no waste of resources.

Should I maybe do something like:

if ($child->(isChild)) {
require "child libraries";
} else {
require "parent libraries";
}

And then "use PackageX" inside those libraries... will that have the
packages called at run time (not called if not needed) rather than at
compile time as in a normal "use X"? Or is my understanding way short
here?

Presumably, there will be multiple children, right? So would you rather
pay the cost once at compile time for good and all; or pay it once per
child at run time?

##Warning: playing with fork bombs is dangerous. Don't try this at home##

$ time perl -le 'fork foreach (1..12); require CGI; do {$foo= wait} \
until $foo==-1;'
106.230u 18.230s 2:10.57 95.3% 0+0k 0+0io 317824pf+0w

$ time perl -le 'require CGI; fork foreach (1..12); do {$foo= wait} \
until $foo==-1;'
0.840u 6.550s 0:07.71 95.8% 0+0k 0+0io 12689pf+0w

$ time perl -le 'fork foreach (1..12); use CGI; do {$foo= wait} \
until $foo==-1;'
0.700u 6.020s 0:06.95 96.6% 0+0k 0+0io 12689pf+0w


Xho

 

[xhoster]

I'm still trying to work out the best way to do this... now I'm
wondering if I can fork() in the constructor and then exec() in it as
well, so the child would never return from the constructor it would
just end and be replaced witht he child process,

I don't see what you hope to gain by this. If you don't want the child
process to return, then don't have it return. No exec is needed to
accomplish this.


package Child;

sub new {
my $pid=fork();
die $! unless defined $pid;
unless ($pid) {
## do childish stuff here
## when you are done:
exit;
} else {
## make the parent's interface to the child.
return bless {child_pid => $pid};
};
};

Xho

 

[Charles DeRykus]

I'm trying to plan out a program and I have a couple questions (which
I've looked up but couldn't find a satisfactory answer for).

1) Is there anything inherently wrong with calling fork() within the
constructor for my object? I'm trying to make a program that works
similar to something like apache, it has a parent that creates many
children which it manages. I have a "child" class which I use to create
child objects something like:

$child = Child->new();
if ($child->(isChild)) {} else {}

The object would know if it were the child by what fork() returns.

Your subsequent post suggests you want the child to exec. The
exec simply replaces the overwritten process with a new exec`ed
process without changing the child process id. The parent still
normally performs a wait on a child process (or the exec'ed
replacement) to reap the child and determine its exit status.

I'd suggest taking a look at perlipc (perldoc perlpic) for in depth
coverage.

2) The children and the parent both need some modules, like DBI, but
some are needed by one but not the other. Is there a problem putting
"use PackageX" for evrey package both processes will need or would that
be wasting resources? Should I maybe do something like:

if ($child->(isChild)) {
require "child libraries";
} else {
require "parent libraries";
}

And then "use PackageX" inside those libraries... will that have the
packages called at run time (not called if not needed) rather than at
compile time as in a normal "use X"? Or is my understanding way short
here?

Usually, you'd simply 'use PackageX' prior to forking to guarantee
availability in both parent and child. But you could 'require' as
you've suggested, or, even easier, 'use autouse DBI' for an "as needed"
load (perldoc autouse)

3) Are there any good books out there on writing these kinds of
programs in perl? This is a web crawler search engine, but I'm
interested in the design aspects of these kinds of programs, which I
suppose aren't language specific. I'm not finding much good information
on managing persistent daemon-style programs or database design for
search engines.

Possiblity Lincoln Stein's "Network Programming with Perl" but there're
probably others which are more specific to search engines.

hth,

 

[hobosalesman]

Thanks for the responses. I realize my initial approach was a bit
screwy. I still have a fork/exec inside the constructor for the child
object, but I understand what I'm doing a bit better.

As for the packages, what I've done is create a 'Spider' package, and
two derived classes 'Spider:arent' and 'Spider::Child'. That way I
can put all the functions and packages that both will need inside the
base class, but still keep what each program needs exclusively
seperate. I'm using them as objects not as classes, calling methods and
not accessing class data directly. That's the best approach I can come
up with as of now... I have a lot of books on order. I appreciate
anyone taking the time to read/respond.