On Jan 30, 2004, at 4:53 PM, Bruce Momjian wrote:
Actually, thinking about this a bit more, that might not even be
necessary. Is SIGPIPE-via-(read|write) synchronous or asynchronous?
(I.e., is the SIGPIPE guaranteed to arrive during the offending system
call?) I was thinking not, but maybe yes. I c
OK, thanks.
---
Scott Lamb wrote:
> On Jan 30, 2004, at 4:53 PM, Bruce Momjian wrote:
> >> Actually, thinking about this a bit more, that might not even be
> >> necessary. Is SIGPIPE-via-(read|write) synchronous or asynchron
Scott Lamb wrote:
> Scott Lamb wrote:
> > You could just do a pthread_sigmask() before and after the
> > pthread_setspecific() to guarantee that no SIGPIPE will arrive on that
> > thread in that time. I think it's pretty safe to assume that as long as
> > you're not doing a pthread_[gs]etspecifi
Scott Lamb wrote:
> You could just do a pthread_sigmask() before and after the
> pthread_setspecific() to guarantee that no SIGPIPE will arrive on that
> thread in that time. I think it's pretty safe to assume that as long as
> you're not doing a pthread_[gs]etspecific() on that same pthread_key
Scott Lamb wrote:
You could just do a pthread_sigmask() before and after the
pthread_setspecific() to guarantee that no SIGPIPE will arrive on that
thread in that time. I think it's pretty safe to assume that as long as
you're not doing a pthread_[gs]etspecific() on that same pthread_key_t,
it'
Bruce Momjian wrote:
Scott Lamb wrote:
Speaking of async signal-safe functions, pthread_getspecific() isn't
specified to be (and thus PQinSend() and thus
sigpipe_handler_ignore_send()). It's probably okay, but libpq is
technically using undefined behavior according to SUSv3.
Yikes. I never s
On Fri, Jan 30, 2004 at 11:10:49AM -0600, Scott Lamb wrote:
> On Jan 30, 2004, at 3:18 AM, Bruce Momjian wrote:
> >Manfred Spraul wrote:
> >>Bruce Momjian wrote:
> >>
> >>>Woh, as far as I know, any application should run fine with
> >>>-lpthread,
> >>>threaded or not. What OS are you on? This i
Scott Lamb wrote:
> Speaking of async signal-safe functions, pthread_getspecific() isn't
> specified to be (and thus PQinSend() and thus
> sigpipe_handler_ignore_send()). It's probably okay, but libpq is
> technically using undefined behavior according to SUSv3.
Yikes. I never suspected pthrea
On Jan 30, 2004, at 3:18 AM, Bruce Momjian wrote:
Manfred Spraul wrote:
Bruce Momjian wrote:
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.
Perhaps we should try to figure out how oth
Manfred Spraul wrote:
> Bruce Momjian wrote:
>
> >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.
> >
> >
> Perhaps we should try to figure out how other packages handle
> multith
Bruce Momjian wrote:
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.
Perhaps we should try to figure out how other packages handle
multithreaded/singlethreaded libraries? I'm looking a
On Jan 27, 2004, at 1:16 PM, Steve Atkins wrote:
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.
It's
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
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 applica
On Fri, Jan 23, 2004 at 10:03:30PM -0500, Bruce Momjian wrote:
> Steve Atkins wrote:
> > When I rebuilt libpq to use threads, I started seeing a bunch of weird
> > failures in many of the older applications. The change in libpq meant
> > that libpthread was being dynamically linked into the non-thr
Steve Atkins wrote:
> (I hope this is -hackers appropriate - feel free to point me elsewhere)
>
> I'm using 7.4.1 as the backend to several applications. Until recently,
> I've been developing solely single-threaded applications.
>
> I just rebuilt postgresql with --enable-thread-safety, to work
(I hope this is -hackers appropriate - feel free to point me elsewhere)
I'm using 7.4.1 as the backend to several applications. Until recently,
I've been developing solely single-threaded applications.
I just rebuilt postgresql with --enable-thread-safety, to work with
some multi-threaded code.
17 matches
Mail list logo
