httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Urp(!) - indeterminant connection SO_NONBLOCK state?
Date Tue, 04 Oct 2005 22:28:37 GMT
William A. Rowe, Jr. wrote:
> Joe Orton wrote:
>>
>> Dies how, what error, what is the server left doing?  This needs 
>> further diagnosis; truss the server, loglevel debug output, etc.  Does 
>> it work on the trunk?
> 
> Ok - I added the same disallow-empty brigade logic that's in the core
> ap_rgetline_core() - just to prove up/prove down that this is a problem.

This modified mod_echo.c is attached - which also does some scoreboard
tracking (and proves up mod_status.c is wrong, we -can- and should
display the request, etc; we really need two modes, one SERVER_BUSY_READ
and SERVER_BUSY_READBODY - after the request headers were processed in
the http protocol handler).

The resulting error is;

[Tue Oct 04 09:18:51 2005] [info] ProtocolEcho: Error - read empty 
brigade from 10.0.8.13!

Here's a snip...

poll(0xFC407BE0, 2, -1)         (sleeping...)
lwp_sema_wait(0xFE807E30)       (sleeping...)
door_return(0x00000000, 0, 0x00000000, 0) (sleeping...)
poll(0xFC407BE0, 2, -1)                         = 1
accept(5, 0x0017CC84, 0x0017CCA4, 1)            = 10
fcntl(9, F_SETLKW, 0xFF2DD2E8)                  = 0
lwp_sema_post(0xFE807E30)                       = 0
lwp_sema_wait(0xFE807E30)                       = 0
lwp_mutex_wakeup(0xFF0C5558)                    = 0
lwp_mutex_lock(0xFF0C5558)                      = 0
lwp_sema_post(0xFE705E30)                       = 0
lwp_sema_wait(0xFE705E30)                       = 0
lwp_mutex_wakeup(0xFF0C5558)                    = 0
lwp_mutex_lock(0xFF0C5558)                      = 0
getsockname(10, 0x0017CC3C, 0x0017CC5C, 1)      = 0
read(10, 0x00180BD8, 8000)                      Err#11 EAGAIN
write(6, " [ T u e   O c t   0 4  ".., 91)      = 91
shutdown(10, 1, 1)                              = 0
fcntl(9, F_SETLKW, 0xFF2DD2C4)                  = 0
poll(0xFE7057A0, 1, 2000)                       = 1
read(10, 0xFE7059A8, 512)                       = 0
close(10)                                       = 0
lwp_cond_wait(0xFF0C5548, 0xFF0C5558, 0xFF0BEDB0) (sleeping...)

As you can see, read returns EAGAIN, and nothing in the core GETLINE
mode handles the manditory retry on APR_BLOCK mode.

Apparently on linux, we set up the sockopt differently...

[pid 18543] poll([{fd=4, events=POLLIN, revents=POLLIN}, {fd=3, 
events=POLLIN}], 2, -1) = 1
[pid 18543] accept(4, {sa_family=AF_INET6, sin6_port=htons(56559), 
inet_pton(AF_INET6, "::ffff:127.0.0.1", &sin6_addr), sin6_flowinfo=0, 
sin6_scope_id=0}, [28]) = 8
[pid 18543] semop(163843, 0x89e752, 1)  = 0
[pid 18543] futex(0x912fb1c, FUTEX_WAKE, 1 <unfinished ...>
[pid 18540] <... futex resumed> )       = 0
[pid 18543] <... futex resumed> )       = 1
[pid 18540] futex(0x912fb18, FUTEX_WAIT, 2, NULL <unfinished ...>
[pid 18543] futex(0x912fb18, FUTEX_WAKE, 1 <unfinished ...>
[pid 18540] <... futex resumed> )       = -1 EAGAIN (Resource 
temporarily unavailable)
[pid 18543] <... futex resumed> )       = 0
[pid 18540] futex(0x912fb18, FUTEX_WAKE, 1 <unfinished ...>
[pid 18543] semop(163843, 0x89e74c, 1 <unfinished ...>
[pid 18540] <... futex resumed> )       = 0
[pid 18543] <... semop resumed> )       = 0
[pid 18543] poll( <unfinished ...>
[pid 18540] futex(0x912fae4, FUTEX_WAKE, 1) = 0
[pid 18540] getsockname(8, {sa_family=AF_INET6, sin6_port=htons(8007), 
inet_pton(AF_INET6, "::ffff:127.0.0.1", &sin6_addr), sin6_flowinfo=0, 
sin6_scope_id=0}, [28]) = 0
[pid 18540] gettimeofday({1128449197, 353743}, NULL) = 0
[pid 18540] read(8, "test\r\n", 8000)   = 6
[pid 18540] writev(8, [{"test\r\n", 6}], 1) = 6

and thus, we have some data captured in the first call by mod_echo.

Notice the -big- difference.  On linux, we hit poll() before read().

On solaris, for some oddball reason, we don't poll, we don't loop.
Not pretty.

Bill

Mime
View raw message