Re: [AOLSERVER] aolserver4 bad file descriptor errors

[Jim Davidson]

Hi,   Seems like firstClosePtr at least is protected -- there's an informatively named Ns_Mutex defined:   static Ns_Mutex lock;     /* Lock around close list and shutdown flag. */   and then in NsSockClose:   void NsSockClose(Sock *sockPtr, int keep) {   ...     Ns_MutexLock(&lock);     if (firstClosePtr == NULL) {          trigger = 1;     }     sockPtr->keep = keep;     sockPtr->nextPtr = firstClosePtr;     firstClosePtr = sockPtr;     Ns_MutexUnlock(&lock);     if (trigger) {          SockTrigger();     } }     and in DriverThread:   static void DriverThread(void *ignored) {  ...   /*   * Check for shutdown and get the list of any closing or   * keepalive sockets.   */    Ns_MutexLock(&lock);  sockPtr = firstClosePtr;  firstClosePtr = NULL;  stopping = shutdownPending;  Ns_MutexUnlock(&lock);     I've debugged a similar problem before -- turned out to be a misbehaved module closing sockets twice or something.  Are you getting these bad file errors with simple nsd/nssock only configs?   -Jim           In a message dated 7/10/2003 11:26:26 AM Eastern Daylight Time, [EMAIL PROTECTED] writes: But Ns_ConnClose is called from within connection thread and is using mutex for firstClosePtr but at the same time single threaded driver.c is using the same pointer without any mutexes. After i put mutex there i started receiving much less "Bad file descriptor" errors and crashes which may be unrelated completely but on my fast dual-CPU machine with many concurrent connections that might be the case. Jim Davidson wrote: > > Hi, > > I'm not sure this is the case.  Code in driver.c is single-threaded by > design, i.e., there's a single "driver thread" which accepts new > connections, does the read-ahead, dispatches the sockets with pre-read > content to the thread pools for service, receives the sockets back for > keep-alive or graceful close.  This is why the various lists and > counters don't have locks around them.  The design assumption is this > single thread can "spin" fast enough to keep a reasonable thread pool > filled with incoming requests. > > For NsSockClose, note there is a lock around the firstClosePtr list > which is the list to return sockets to the driver thread.  Sockets are > put there and a trigger is sent for driver to pull them off. > > Anyway, that's the plan -- I could have missed something and allowed > these lists to be fiddled by other threads by accident. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.