httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <>
Subject Re: 2.0/dexter locking wierdness?
Date Tue, 01 Feb 2000 17:57:07 GMT
Note: I'm not very involved with code these days; I should be diving
back into the code in a week or two. I'll be very happy if someone
else fixes this stuff first, though (hint hint).

On Tue, Feb 01, 2000 at 05:37:55AM -0800, Dale Ghent wrote:
> From looking at the resulting output, 
> the only abnormal thing that happens right before the process enters into
> the runaway write() state is that fcntl() fails right after accept()ing a
> connection with EDEADLK.

That's just weird. I can only think of a couple of cases where we'd
even have multiple locks, and none where we could possibly have a
deadlock condition. 

> From that point on, all write()s for all threads
> in that apache process then loop and fail constantly with EPIPE.

Hmmm. Every socket that gets opened is reclosed somehow? *shrug*

IIRC, Solaris 2.x was supposed to support cross-process pthread
locking, so I'd imagine Solaris 7 does by now. Are you familiar enough
with autoconf to try changing the default cross-process lock in APR to
a shared pthread mutex?

Note: I think we're eventually going to have to replace or supplement
any dynamic lock checks we have with some of the data we've collected from
1.3 on what actually works and what doesn't.

> I saved the truss output to a file, and it is available at:

Hmmmm, looks like Apache is completely ignoring return values from the
write() calls. The /nn: at the beginning of the line is a thread
number, right?

Whoa! Why is APR's ap_send call *always* returning APR_SUCCESS? This
could explain why Apache isn't reacting to the EPIPE. 

View raw message