In the source code that I posted earlier you are correct. But I tested that after changing that code a bit. I called 'sqlite3_close' just after I called 'sqlite3_open'. Then also I am not getting correct PID inside the thread.
So can I do just a 'open' and 'close' of sqlite in parent process and then I create the child process? On 10/4/07, John Stanton <[EMAIL PROTECTED]> wrote: > > You are not only accessing an Sqlite connection across threads, but also > processes! > > Create the DB connection in the thread in which it is being used and you > will obey the needs of all versions of Sqlite. > > One da6tabase may be used across processes provided that you create the > connection according to the Sqlite rules and do it in the thread of > execution. > > Sabyasachi Ruj wrote: > > I read that. > > But it prohibits to use SQLite open handles across processes. > > It is not written that one database should not be used acoross process. > > I am carrying any sqlite open across processes. > > > > Before creating the daemon:- > > I am opening sqlite > > doing something > > closing sqlite. > > > > But then also the problem persists. > > > > I mean I am not getting the process id of the CHILD PROCESS inside the > > threads > > (which has created the threads). > > > > But in that CHILD process, the pid is OK(it returns its id, not of the > > PARENT PROCESS). > > > > > > > > Thanks for your repply. > > > > On 10/4/07, Rich Rattanni <[EMAIL PROTECTED]> wrote: > > > >>Just read this today, after doing some other research. Does this help > >>any? > >> > >>http://www.sqlite.org/faq.html#q6 > >> > >>It says, in a nutshell, don't use a database across forks. > >> > >>On 10/3/07, John Stanton <[EMAIL PROTECTED]> wrote: > >> > >>>How do you know that when your process forks that you are looking at > the > >>>child, not the parent? > >>> > >>>Sabyasachi Ruj wrote: > >>> > >>>>Hi, > >>>> > >>>>I am writing an application which will continue to execute as a > >> > >>'daemon' in > >> > >>>>Linux. > >>>>The application is multi threaded. > >>>>And once the daemon is created, it will create few threads to perform > >> > >>some > >> > >>>>tasks. > >>>> > >>>>>From here, I'll refer the 'process before creating the daemon' as > >> > >>'PARENT > >> > >>>>PROCESS', > >>>>and 'process after creating the daemon' as 'CHILD PROCESS'. > >>>> > >>>>So the threads are being created in CHILD PROCESS. > >>>> > >>>>I need to get the process id (PID) in those threads. > >>>> > >>>>Here is my problem! > >>>> > >>>>If I have called 'sqlite3_open' BEFORE creating the daemon, > >>>>then the PID I am getting inside the thread, is the PID of the > >>>>'PARENT PROCESS', not the 'CHILD PROCESS'! > >>>> > >>>>But as after creating the daemon, the PARENT PROCESS gets killed, > >>>>those are invalid PIDs. > >>>> > >>>>This happens ONLY if I am calling the 'sqlite3_open' before creating > >> > >>the > >> > >>>>daemon! > >>>> > >>>> > >>>>I am not getting if this is the expected behavior or not. > >>>> > >>>> > >>>>Herewith I am attaching one sample test project, that will depict the > >> > >>issue. > >> > >>>>It is having one Makefile. The executable will be named as: pidtest > >>>> > >>>>To execute that process as a daemon use the '-d' command line > >> > >>argument. > >> > >>>>For example:- > >>>>./pidtest -d > >>>> > >>>>This process will create one log file called 'log.txt' in the current > >>>>directory. > >>>>which will show the output. > >>>> > >>>>For limitation on size of the mail,I have removed SQLite source code(' > >>>>sqlite3.c' and 'sqlite3.h'). > >>>>I am using amalgamated code, version 3.4.0. > >>>>Checked with the latest 3.4.2. The problem is same. > >>>> > >>>> > >>>> > >>>> > >> > >>------------------------------------------------------------------------ > >> > >>>> > > >>----------------------------------------------------------------------------- > >> > >>>>To unsubscribe, send email to [EMAIL PROTECTED] > >>>> > >> > > >>----------------------------------------------------------------------------- > >> > >>> > >>> > > >>----------------------------------------------------------------------------- > >> > >>>To unsubscribe, send email to [EMAIL PROTECTED] > >>> > >> > > >>----------------------------------------------------------------------------- > >> > >>> > >> > > >>----------------------------------------------------------------------------- > >>To unsubscribe, send email to [EMAIL PROTECTED] > >> > > >>----------------------------------------------------------------------------- > >> > >> > > > > > > > > > > ----------------------------------------------------------------------------- > To unsubscribe, send email to [EMAIL PROTECTED] > > ----------------------------------------------------------------------------- > > -- Sabyasachi
