Re: Mixing threaded and non-threaded

On Tue, Jan 27, 2004 at 02:07:44PM -0500, Bruce Momjian wrote:
> Steve Atkins wrote:
> > > My guess is that creating applications against the non-thread libpq and
> > > then replacing it with a threaded libpq is your problem.
> >
> > Yes. It seems to make no difference whether the application is rebuilt
> > or not. It's pulling libpthread into a non-thread-aware application
> > that's the problem.
> >
> > The only fix that would allow the non-threaded application to work
> > with a thread-safe libpq would be to rewrite it to be a threaded
> > application with a single active thread.
>
>
> Woh, as far as I know, any application should run fine with -lpthread,
> threaded or not. What OS are you on? This is the first I have heard of
> this problem.

Linux/i386, RedHat 7.something, gcc 2.96. Not my favorite
configuration, but nothing particularly odd.

> > > I guess the
> > > question is whether you would like to have two libpq's and have to
> > > decide at link time if you wanted threading, or just have one libpq and
> > > make sure you recompile if you change the threading behavior of the
> > > library. We considered the later to be clearer.
> >
> > Recompiling doesn't neccesarily help unless the application is also
> > rewritten. Also, if there are dozens of non-threaded applications
> > using libpq on a system (possibly installed via rpms or equivalent)
> > then replacing the system libpq could break something else.
>
> Why? How would you rewrite it?

No idea. I've not looked at exactly what's going on, yet.

It's perfectly possible that the problem I'm seeing is actually a bug
in the underlying code - but it's been used in heavy production use
for two years without pthread, and deadlocked immediately when built
with pthread, so it's the sort of bug that could be elsewhere.

It's a very complex application, so I'd really need to reduce it to
a test case to narrow it down.

A hint, though, might be that it's a multiprocess application with a
single master process that controls dozens of child processes. When the
master shuts down it asks all the children to shut down, and then it
deadlocks in the SIGCHILD handler.

I'll burrow a bit deeper when I get some time.

Cheers,
Steve