Sponsored Content
Top Forums Programming socket close() -w- pthreads linux 2.6.18.2-34 (suse) SMP Post 302164685 by ramen_noodle on Tuesday 5th of February 2008 03:04:36 PM
Old 02-05-2008
socket close() -w- pthreads linux 2.6.18.2-34 (suse) SMP

Interesting issue. There was some discussion on the LKML last year regarding the potential problems in concurrent applications reusing file descriptors in various scenarios. The main issue is that the reuse of a file descriptor and reception of data in a threaded application can be confused pretty easily.

Alan Cox suggested using shutdown() before close() to deal with one of the most glaring reuse problems. This doesn't seem to work 100% either.

If I have code like this:
Code:
extern void *handleclient(void *arg) {
int rd = -1;
long mcount = 0;
VHNDL in;
char buf[BSZ];
                         pthread_detach(pthread_self());       
                         pthread_mutex_lock(&socketstable);  
                         memcpy(&in,arg,sizeof(in));
                         pthread_mutex_unlock(&socketstable);
                         while ( (rd = read(in.c_sock,buf,BSZ)) > 0) {
                                 printf("TID %d: Read message %d from peer at %s = %s\n",pthread_self(),mcount++,inet_ntoa(in.peer.sin_addr),buf);
                                 bzero(buf,BSZ);
                         }
                         /*pthread_mutex_lock(&socketstable);*/
                         shutdown(in.c_sock,SHUT_RDWR);
                         close(in.c_sock);
                        /*pthread_mutex_unlock(&socketstable);*/
                         pthread_exit(NULL);
}

The reuse of file descriptors still causes EBADF in some cases. The parent process is simple in an accept() loop creating handler threads till MAXTHREADS then recycling. As you see the handler does nothing but read till error and then exits.
I'm still getting EBADF on some closes and as a result having incrementing numbers of close-wait connects.

Any ideas?
 

7 More Discussions You Might Find Interesting

1. Programming

C Prog to close a socket in established state

I have a SUN environment running an WebLogic that communicates w/a 3rd party running IIS. When the IIS site goes down (frequently), I am stuck with sockets in an ESTABLISHED state, and cannot seem to figure out how to avoid this. No exceptions are thrown as I can still open connections to the IIS... (1 Reply)
Discussion started by: teledelux
1 Replies

2. UNIX for Dummies Questions & Answers

SMP support in Linux 7.3

What is the SMP support like when you are running Linux 7.3 on a system with 2-4 CPUs? (3 Replies)
Discussion started by: AngryRabbi
3 Replies

3. Linux Benchmarks

Dual Intel Xeon 2.4Ghz - Linux 2.4.26 SMP

System: CPU/Speed: Dual Intel Xeon 2.4Ghz Ram: 2 GB DDR 266 SDRAM Motherboard: SuperMicro X5DE8-GG Bus: 533MHz/400MHz system bus - Cache: 512KB HD Controller: EIDE Serverworks™ GC-SL Chipset Extra GCC compiler flags: -s... (3 Replies)
Discussion started by: Neo
3 Replies

4. HP-UX

socket close hangs and CPU go to 100%

Hello, I'm currently having a problem with HPUX. The application is a C app. It's a socket server. It runs mostly fine, but under some circumstances (I can not replicate it), the app hangs and the CPU goes to 100%. I have use gdb to attach to the app, and it was doing a close(). the... (0 Replies)
Discussion started by: arico
0 Replies

5. HP-UX

Close Socket at HP-UX

Hi all, I have a HP-UX 11.23 that have a Server establishing connections on port 8888 . The problem is that when i need to stop and restart the Server, the connections mantain the same state and i need to wait about 20-30 minutes before all connections finishes. The connections remain at... (2 Replies)
Discussion started by: Renato Gregio
2 Replies

6. UNIX and Linux Applications

any way to close socket

I have written a socker program. I have executed that program many times without closing the socket. So I want to find which all sockets binded with which file descriptor. Is there any way to close those socket, which have been opened in that program's execution. please help me!.. (3 Replies)
Discussion started by: pa.chidhambaram
3 Replies

7. IP Networking

Is it necessary to close socket after a unstop loop?

Is the last two line necessary? #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> int main(void) { struct sockaddr_in stSockAddr; ... (0 Replies)
Discussion started by: vistastar
0 Replies
CLOSE(2)						      BSD System Calls Manual							  CLOSE(2)

NAME
close -- delete a descriptor LIBRARY
Standard C Library (libc, -lc) SYNOPSIS
#include <unistd.h> int close(int fd); DESCRIPTION
The close() system call deletes a descriptor from the per-process object reference table. If this is the last reference to the underlying object, the object will be deactivated. For example, on the last close of a file the current seek pointer associated with the file is lost; on the last close of a socket(2) associated naming information and queued data are discarded; on the last close of a file holding an advisory lock the lock is released (see further flock(2)). However, the semantics of System V and IEEE Std 1003.1-1988 (``POSIX.1'') dictate that all fcntl(2) advisory record locks associated with a file for a given process are removed when any file descriptor for that file is closed by that process. When a process exits, all associated file descriptors are freed, but since there is a limit on active descriptors per processes, the close() system call is useful when a large quantity of file descriptors are being handled. When a process forks (see fork(2)), all descriptors for the new child process reference the same objects as they did in the parent before the fork. If a new process is then to be run using execve(2), the process would normally inherit these descriptors. Most of the descriptors can be rearranged with dup2(2) or deleted with close() before the execve(2) is attempted, but if some of these descriptors will still be needed if the execve fails, it is necessary to arrange for them to be closed if the execve succeeds. For this reason, the call ``fcntl(d, F_SETFD, FD_CLOEXEC)'' is provided, which arranges that a descriptor will be closed after a successful execve; the call ``fcntl(d, F_SETFD, 0)'' restores the default, which is to not close the descriptor. RETURN VALUES
The close() function returns the value 0 if successful; otherwise the value -1 is returned and the global variable errno is set to indicate the error. ERRORS
The close() system call will fail if: [EBADF] The fd argument is not an active descriptor. [EINTR] An interrupt was received. [ENOSPC] The underlying object did not fit, cached data was lost. [ECONNRESET] The underlying object was a stream socket that was shut down by the peer before all pending data was delivered. In case of any error except EBADF, the supplied file descriptor is deallocated and therefore is no longer valid. SEE ALSO
accept(2), closefrom(2), execve(2), fcntl(2), flock(2), open(2), pipe(2), socket(2), socketpair(2) STANDARDS
The close() system call is expected to conform to ISO/IEC 9945-1:1990 (``POSIX.1''). HISTORY
The close() function appeared in Version 7 AT&T UNIX. BSD
September 11, 2013 BSD
All times are GMT -4. The time now is 01:29 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy