Re: Initializing Sleepycat::DbXml (Berkeley, Oracle) objects in startup.pl

[Michael Ludwig]

macke...@animalhead.com schrieb:

What I did to get worker and event working under FreeBSD 6.3,
was to eliminate the child_init handler, and at the start of
the response handler do something like

my $env;

 sub handler { # this is the response handler
    my ($r) = @_;
    if (!$env) {
        $env = DbEnv->new;
        $env->open( $envdir, Db::DB_USE_ENVIRON | Db::DB_THREAD);
        ...
       }
    ...
 }

Guten Abend, Craig!

Thanks for replying again. What you've outlined above is what I had
implemented following Mark's suggestion in his first reply to my initial
post. Unfortunately, this quite reliably produces SEGVs, so I think this
usage is not aligned with the Berkeley interface design. I don't know in
which way this is wrong - I guess I'll have to ask the Berkeley folks in
order to maybe clarify this.

What this means is that each thread must open the db's for itself.
The amount of data stored for each open DB connection, times
THREADS_PER_CHILD times the number of Apache children at any
given point, makes for some memory.  But

1) the separate connections help the DB package be thread-safe,

So if coding the handler as above means that each thread, having its own
global variables, opens its own handle to the Berkeley environment, I
shouldn't need the DB_THREAD flag (which, according to the Berkeley
documentation, "[causes] the DbEnv handle returned by DbEnv::open to be
free-threaded; that is, concurrently usable by multiple threads in the
address space." This flag is needed if any handle is used by more than
one thread (or process) concurrently. So it shouldn't be needed if the
handler is coded as above and there isn't any concurrent access
elsewhere.

2) the first-used threads keep getting re-used in preference to
   threads not yet used.

I noticed this is indeed what seems to happen - whether by chance or as
a feature, I don't know.

3) if you consider each thread as more or less equivalent to a
   child process in prefork, your total memory requirement is less.

From perldoc perlthrtut: "In this model each thread runs in its own Perl
interpreter, and any data sharing between threads must be explicit."
This does not sound to me as if there is a significant advantage over
spawning child processes, at least not on UNIX.

Hmm. Not sure what to make of this threaded Perl.

Michael Ludwig