On Mon, Jul 12, 2010 at 11:25:07PM -0700, Roger Binns wrote:
> > No, just entry points into the library. What makes you think that I
> > meant that every function in the library should check this?
>
> I also meant entry points but wasn't specific. There are a lot of them that
> acquire/release
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/12/2010 08:53 PM, Nicolas Williams wrote:
> On Mon, Jul 12, 2010 at 08:43:32PM -0700, Roger Binns wrote:
>> Earlier you were trying to optimise out calls to getpid() and now you want
>> every SQLite function source to be changed?
>
> No, just
On Mon, Jul 12, 2010 at 08:43:32PM -0700, Roger Binns wrote:
> > They're insane (the _first_, not last, fildes close(2) in a process
> > drops all locks on the underlying file), but the child won't clobber the
> > parent's locks.
>
> That is assuming all components (C libraries, threading,
On Mon, Jul 12, 2010 at 08:43:32PM -0700, Roger Binns wrote:
> Earlier you were trying to optimise out calls to getpid() and now you want
> every SQLite function source to be changed?
No, just entry points into the library. What makes you think that I
meant that every function in the library
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/12/2010 02:59 PM, Nicolas Williams wrote:
> You can return an error to the caller too.
That would require substantial surgery to SQLite. Almost every routine
acquires and releases locks so they would have to be changed along with
SQLite
On Mon, Jul 12, 2010 at 02:47:19PM -0700, Roger Binns wrote:
> About the only correct thing to do in a process using SQLite through a fork
> is to terminate the process.
You can return an error to the caller too. Of course, if you're using
the mutex functions to do this then it's too late, so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/12/2010 12:07 PM, Eric Smith wrote:
> I don't think the devs would complain about that. "This code has too
> few lines!"
They also have to have signed paper copies dedicating the code to public
domain and acknowledging the right to do so.
Roger Binns wrote:
> I'd have no problem contributing the code to SQLite, but there isn't
> very much of it
I don't think the devs would complain about that. "This code has too
few lines!"
> and it is an open issue as to how you report the cross fork usage should
> it happen. (In my case
On Mon, Jul 12, 2010 at 01:59:30PM -0500, Nicolas Williams wrote:
> The result is that you end up with a tiny penalty for fork
> detection: two loads, a compare and a likely-not-taken branch.
Actually three loads, two compares and two likely-not-taken branch,
unless you know you
On Sat, Jul 10, 2010 at 11:27:41AM -0700, Roger Binns wrote:
> On 07/10/2010 07:12 AM, Eric Smith wrote:
> > Your wrapper is nice -- have you considered folding something like it
> > into the core (disabled by default, enabled by a compile-time flag) and
> > submitting it to drh for official
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/10/2010 07:12 AM, Eric Smith wrote:
> Your wrapper is nice -- have you considered folding something like it
> into the core (disabled by default, enabled by a compile-time flag) and
> submitting it to drh for official adoption?
DRH and the
Roger Binns wrote:
> I'll bet you are actually getting exit(3) which means anything
> registered with atexit will be run. (SQLite does not register with
> atexit.)
I knew what Nico meant :) just repeated him for expositional clarity
(deeming the distinction to be unimportant for my
On Fri, Jul 09, 2010 at 02:38:08PM -0700, Roger Binns wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 07/09/2010 02:31 PM, Nicolas Williams wrote:
> > 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/09/2010 02:31 PM, Nicolas Williams wrote:
> 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().
That
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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
On Fri, Jul 09, 2010 at 04:52:35PM -0400, Eric Smith wrote:
>
> > I strongly recommend that you always make the child side of fork(2)
> > either exit(2) or exec(2) immediately.
>
> Sorry Nico, I never saw this response -- I appreciate it!
>
> What do you mean, "immediately"?
Good question.
> I strongly recommend that you always make the child side of fork(2)
> either exit(2) or exec(2) immediately.
Sorry Nico, I never saw this response -- I appreciate it!
What do you mean, "immediately"? As I said, my child comes to life,
does some work without touching (its copy of) existing
On Mon, Jun 28, 2010 at 11:30:49AM -0400, Eric Smith wrote:
> From the docs:
>
> > Under Unix, you should not carry an open SQLite database across a
> > fork() system call into the child process. Problems will result if you
> > do.
>
> What if I fork a process that promises not to use the
>From the docs:
> Under Unix, you should not carry an open SQLite database across a
> fork() system call into the child process. Problems will result if you
> do.
What if I fork a process that promises not to use the handle, and
furthermore the child process certainly dies before the parent
20 matches
Mail list logo
