+-- On Aug 14, Andrew Piskorski said:
In AOLserver 3.x (and 3.3+ad13 in particular), I believe that a
connection thread continues to execute until it eiter finishes all the
code it's running or errors out. The thread never knows that the
client is no longer waiting for a request, and
I just looked at the socket code, the main part being in nsd/sock.c:
---
Ns_SockSend(SOCKET sock, void *buf, int towrite, int timeout)
{
int nwrote;
nwrote = send(sock, buf, towrite, 0);
if (nwrote == -1
ns_sockerrno == EWOULDBLOCK
Ns_SockWait(sock, NS_SOCK_WRITE,
+-- On Aug 14, Andrew Piskorski said:
Or is it just that ns_write will block if the
socket send buffer is full?
I believe that's the case. ns_write just puts the data into the kernel's
socket buffer and returns immediately if possible.
And if so, how do I find out how big my
TCP/IP
I don't know how much this will help...
It's a fairly common feature of socket implementations that send() over a
tcp connection may not write all of the data, which is why it returns the
amount of data written. The amount written in one call depends on various
network conditions -- if you
im using aolserver 3.3.1 + ad on RH7.2.. postgresql 7.1...
i have this IDLE processes in postgres.. only aolserver uses this DBs..
so i was wondering if this processes are caused by unclosed threads on DB
access?
is this normal? if ill be killing this processes would it increase the
efficiency
