Mike Meyer wrote at 2008-1-13 14:07 -0500: > ... >On Sun, 13 Jan 2008 13:10:48 +0100 [EMAIL PROTECTED] wrote: > ... >> >If >> >not, does it need to do anything special, or avoid doing anything, in >> >order to not disrupt the parent processes use of those variables? >> Open a new connection in your forked child. > >Obvious. What do I do with the old one? I started out by explicitly >closing it, but that seems to make oracle unhappy (internal errors of >various kinds).
Your best bet is to leave it alone. If you are lucky (!) then this will be sufficient. As I mentioned, for a ZODB it was not sufficient -- because the child intercepted messages destined for the parent and eat them away. If you face similar problems, give up and "exec" in the forked process. >> I finally abondoned this approach completely (because, LDAP >> was used deeply in my system and I had no control over the creation >> of new connections) and am now using "fork+exec". > >Oddly enough, fork+exec doesn't make the problem go away, just >provides another possible solution. Maybe, you state precisely what problem you have. Usually, it is not a problem that the execed child has some open fds that it does not need. When it is, you can explicitely close all connections, e.g. before you exec. >Open fd's can either be closed on >exec, or not. Hopefully, it's closed because the python objects that >referred to it are lost across the exec. No, they remain open (as the complete memory state is replaces -- there is no way, Python can intercept the "exec"). >I'm willing to believe that >should work. So how do I simulate what happens on exec without >actually doing the exec? You do the "exec" -- you cannot similate it (unless you are using deep and very low level system magic, not directly supported by Python). -- Dieter _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
