On Fri, Jul 09, 2010 at 02:22:37PM -0700, Roger Binns wrote: > On 07/09/2010 01:52 PM, Eric Smith wrote: > > What do you mean, "immediately"? As I said, my child comes to life, > > does some work without touching (its copy of) existing SQLite strucures, > > and then calls exit(2). > > I'll bet you are actually getting exit(3) which means anything registered > with atexit will be run. (SQLite does not register with atexit.)
Oh, duh. I forgot that distinction. Yes, exit(3), not exit(2). (Any library with atexit handlers should check the process' PID if fork- safety is an issue, and do nothing when called on the child side of a fork().) > In my wrapper I provide functionality that can check SQLite objects are not > being used across processes. The way it does this is by providing an > alternate mutex implementation (almost every SQLite operation acquires and > releases mutexes) and verifies the mutex is used in the same process id it > was allocated in. In a benchmark doing only SQLite operations I found a 1% > performance hit. The trick to making that go fast is to use pthread_atfork() to get the new PID on the child side of fork() and store the PID in a global variable so that you don't need to call getpid(). Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
