file-descriptor

Connection pool and File handles

情到浓时终转凉″ 提交于 2019-11-30 10:11:53
We use Retrofit/OkHttp3 for all network traffic from our Android application. So far everything seems to run quite smoothly. However, we have now occasionally had our app/process run out of file handles. Android allows for a max of 1024 file handles per process OkHttp will create a new thread for each async call Each thread created this way will (from our observation) be responsible for 3 new file handles (2 pipes and one socket). We were able to debug this exactly, where each dispached async call using .enqueue() will lead to an increase of open file handles of 3. The problem is, that the

Using stdin with select() in C

左心房为你撑大大i 提交于 2019-11-30 10:07:24
I have the following program: #include <stdio.h> #define STDIN 0 int main() { fd_set fds; int maxfd; // sd is a UDP socket maxfd = (sd > STDIN)?sd:STDIN; while(1){ FD_ZERO(&fds); FD_SET(sd, &fds); FD_SET(STDIN, &fds); select(maxfd+1, &fds, NULL, NULL, NULL); if (FD_ISSET(STDIN, &fds)){ printf("\nUser input - stdin"); } if (FD_ISSET(sd, &fds)){ // socket code } } } The problem I face is that once input is detected on STDIN, the message "User input - stdin" keeps on printing...why doesn't it print just once and on next while loop check which of the descriptors has input ? Thanks. The select

Why do operating systems limit file descriptors?

半城伤御伤魂 提交于 2019-11-30 04:51:23
I ask this question after trying my best to research the best way to implement a message queue server. Why do operating systems put limits on the number of open file descriptors a process and the global system can have? My current server implementation uses zeromq, and opens a subscriber socket for each connected websocket client. Obviously that single process is only going to be able to handle clients to the limit of the fds. When I research the topic I find lots of info on how to raise system limits to levels as high as 64k fds but it never mentions how it affects system performance and why

Empty or “flush” a file descriptor without read()?

笑着哭i 提交于 2019-11-30 01:49:35
问题 (Note: This is not a question of how to flush a write() . This is the other end of it, so to speak.) Is it possible to empty a file descriptor that has data to be read in it without having to read() it? You might not be interested in the data, and reading it all would therefore waste space and cycles you might have better uses for. If it is not possible in POSIX, do any operating systems have any non-portable ways to do this? UPDATE: Please note that I'm talking about file descriptors , not

Why FD_SET/FD_ZERO for select() inside of loop?

我们两清 提交于 2019-11-29 22:20:24
I am using the select function for communication between my sockets. I have a while loop and I do - while(!done) { FD_ZERO(&read_flags); FD_ZERO(&write_flags); FD_SET(comm_fd1, &read_flags); FD_SET(comm_fd2, &read_flags); FD_SET(STDIN_FILENO, &read_flags); FD_SET(comm_fd1, &write_flags); FD_SET(comm_fd2, &write_flags); FD_SET(STDIN_FILENO, &write_flags); //call select sel = select(comm_fd1+comm_fd2+1, &read_flags, &write_flags, (fd_set*)0, &waitd); and the same with different variables on the client side. I got this basic technique from a tutorial online and just went with it. Then it hit me -

IOException: Too many open files

假如想象 提交于 2019-11-29 20:41:55
I'm trying to debug a file descriptor leak in a Java webapp running in Jetty 7.0.1 on Linux. The app had been happily running for a month or so when requests started to fail due to too many open files , and Jetty had to be restarted. java.io.IOException: Cannot run program [external program]: java.io.IOException: error=24, Too many open files at java.lang.ProcessBuilder.start(ProcessBuilder.java:459) at java.lang.Runtime.exec(Runtime.java:593) at org.apache.commons.exec.launcher.Java13CommandLauncher.exec(Java13CommandLauncher.java:58) at org.apache.commons.exec.DefaultExecutor.launch

C socket get IP address from filedescriptor returned from accept

混江龙づ霸主 提交于 2019-11-29 19:09:35
问题 I know this question seems typical and multiple times answered but I think if you read the details it is not so common (I did not find it). The point is that I am developing a unix service in c that opens a socket and waits for connections, when I have a connection I create a new process to treat it , so there can be multiple connections opened at the same time . int newfd = accept(sockfd, (struct sockaddr *)&clientaddr, (socklen_t*)&clientaddr_size); Later on ( after and inside some other

ftell on a file descriptor?

孤街浪徒 提交于 2019-11-29 16:39:56
问题 Is there a way to do what ftell() does (return the current position in the file) on a raw file descriptor instead of a FILE*? I think there ought to be, since you can seek on a raw file descriptor using lseek(). I know I could use fdopen() to create a FILE* corresponding to the file descriptor, but I'd rather not do that. 回答1: Just use: position = lseek(fd, 0, SEEK_CUR); 来源: https://stackoverflow.com/questions/3399236/ftell-on-a-file-descriptor

is it a good practice to close file descriptors on exit

五迷三道 提交于 2019-11-29 16:21:40
问题 If for some reason, I discover a fatal situation in my program, and I would like to exit with an error code. Sometimes, the context of the fatal error is outside the scope of other file-descriptors. is it a good practice to close these file descriptors. As far as I know, these files are automatically closed when the process dies. 回答1: Files are automatically closed, but it's a good practice. See valgrind on this example david@debian:~$ cat demo.c #include <stdio.h> int main(void) { FILE *f; f

Using stdin with select() in C

老子叫甜甜 提交于 2019-11-29 15:15:04
问题 I have the following program: #include <stdio.h> #define STDIN 0 int main() { fd_set fds; int maxfd; // sd is a UDP socket maxfd = (sd > STDIN)?sd:STDIN; while(1){ FD_ZERO(&fds); FD_SET(sd, &fds); FD_SET(STDIN, &fds); select(maxfd+1, &fds, NULL, NULL, NULL); if (FD_ISSET(STDIN, &fds)){ printf("\nUser input - stdin"); } if (FD_ISSET(sd, &fds)){ // socket code } } } The problem I face is that once input is detected on STDIN, the message "User input - stdin" keeps on printing...why doesn't it