[15596] in Kerberos_V5_Development
Re: Project review: Parallel KDC
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Mar 12 14:10:01 2010
From: Greg Hudson <ghudson@mit.edu>
To: "krbdev@mit.edu" <krbdev@mit.edu>
In-Reply-To: <201003112214.o2BMEBnm017380@outgoing.mit.edu>
Date: Fri, 12 Mar 2010 14:09:56 -0500
Message-ID: <1268420997.18898.542.camel@ray>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
I realized that there's a fairly serious complication which I didn't
acknowledge in my design, surrounding the interaction between DB module
initialization and worker processes.
What I have right now is broken, although it happens to work for db2.
I'm initializing the database module in the supervisor, cloning its
state to the workers via fork(), and then using it in the worker
processes. The db2 back end happens to carry around very little
database state since it re-opens the database for each operation, so it
doesn't mind.
I can see two ways to get this right:
1. Defer DB module initialization until the worker processes start.
2. Do DB module initialization in the supervisor as now, but finalize
the modules prior to forking, and reinitialize them in the workers.
The second option is more complicated, but has the advantage that when
the DB module is mis-configured, you get a more orderly failure--an
error in the supervisor prior to opening up the network ports, rather
than a failure and shutdown in each of the workers afterwards.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
