Hi Oliver, I am a little bit confused. First you want to update the configuration in the parent process and second you think that it is not a good idea to place all the data in the parent process (the owner of the "root" context). Is the connector style config something like a configuration server?
If we update the "root" context then every fork creates a copy of this information. I see no difference according to pre-initialization on startup. We could create a queue which only stores a specified maximum number of cross references but what is a good limit? This depends on the capabilities of the server and the use case. If you access the data of the parent process from the child processes then you need IPC and you need locks. If you lock the parent process then you block all new incoming requests. Sounds like I am today in a pessimistic mood ;) Best regards, Michael Am 01.04.2012 08:54, schrieb Oliver Welter: > Hi Michael, > > you are right - Scott pointed to the same direction. > > Do you (or anybody else here) has enough experience with forking and can > show me a a way to share at least some vital cache information between > forks? > > Background: I am migrating the Smartcard Personalization Workflow to use > the new Connector Style Config. We need to create "cross references" on > the config which requires to walk thru the whole tree and that is > extremly slow, so we urgently need to cache the info. > > A workaround would probably be to create this reference tree once on > Server init, so the cached info is in the "root" context and gets > inherited by each child. But that blows up the amount of data that needs > to be copied on each fork. > > Oliver -- ___________________________________________________________________ Michael Bell Humboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 70143 ZE Computer- und Medienservice Fax: +49 (0)30-2093 70135 Unter den Linden 6 [email protected] D-10099 Berlin ___________________________________________________________________ PGP Fingerprint: 09E4 3D29 4156 2774 0F2C C643 D8BD 1918 2030 5AAB
smime.p7s
Description: S/MIME Kryptografische Unterschrift
------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________ OpenXPKI-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-devel
