This question already has answers here:
Portable way to pass file descriptor between different processes
(2 answers)
Closed 9 years ago.
The answer to this question shows how to share a file descriptor between two processes. I am unclear on whether this is possible with any process or only related processes. For example, is it possible to open an unnamed pipe and pass the read or write file descriptor to another unrelated process on a unix system?
Yes, you can pass a file descriptor to any other process. The only requirement is that you open a Unix domain socket to communicate between the two processes.
Related
This question already has answers here:
How to view thread id of a process which has opened a socket connection?
(2 answers)
Closed 3 years ago.
I have a process with 100 threads.
I know that only one thread is using a specific fd.
For example, this fd is a socket descriptor, and only one thread is using this socket with send() and receive().
How can I find out, with C, on Linux, the ID of this thread?
Is there a smarter way than attaching to each thread with ptrace and waiting until one of them will be detected?
File descriptors are part of the process. And since a file descriptor is just a nonnegative integer, and can be used by all threads of the same processes without explicit rebinding, asking "which thread holds an fd" is not a question applicable to the Linux process/threading model.
If you really want an answer then it would be: All the threads do!
This question already has answers here:
Can I share a file descriptor to another process on linux or are they local to the process?
(6 answers)
Closed 6 years ago.
int fd = socket(//arguments);
Can this descriptor be passed to another process via IPC and still be valid or is it local to the process that created it?
File descriptors are local to the process. For instance, every process will have its standard input, output, and error on file descriptors 0, 1, and 2.
It is possible to pass a file descriptor to another process over a UNIX domain socket. When this is done, each process will have a copy of the file descriptor, possibly under a different FD number. It's a kind of messy API, though, and is rarely used.
Yes, file descriptors are local to the process. When a process forks a child, however, the parent and child have the same file descriptor table. This is great because it allows for IO redirection, which is a pretty handy trick.
This question already has answers here:
What are file descriptors, explained in simple terms?
(13 answers)
Closed 8 years ago.
Are C socket descriptor returned by socket() function unique ?
I called this from two programs simultaneously and i got the same output
(socDes = socket(PF_INET, SOCK_MRP, 0)
printf("%d",socDes);
According to its man page, socket() returns a file descriptor for New socket
if two programs have same socket, how the received packets gets transferred to different process ? Any elaboration will be helpful.
Socket descriptors are file system handles, and should be unique to your process for the duration of it's session. But if you end and re-run, you may very well receive the same value.
Keep in mind, each process has it's own list of file system handles. So file descriptor 3 in process 10 can be very different from file descriptor 3 in process 20.
A file descriptor is a process resource. Every program loaded in your system has it's own, independent set of file descriptors. That's why STDOUT/STDIN correspond to FD 1/2 (or is it 0/1?). In practice file descriptors are numeric identifiers to a resource held by the operating system, they just happen to be printable as integers (there's no guarantee about that on all systems, what you're seeing is an implementation detail). In the operating system your FD 1,2,3,etc correspond to different resources than in another process.
Since each process has its own pool of resources it follows that file descriptors would be in separate pools. They just happen to have the same ID because of how those IDs are allocated by the OS!
This question already has answers here:
replace system() with non-blocking function
(5 answers)
Closed 8 years ago.
Please tell me how to open two files simultaneouly using system();
I want to open two file
and I am doing it like
system("C:\temp\file1.doc");
system("C:\temp\file2.doc");
But here till the file 1 is open file 2 is not opening as the control is not able to reach the second system call , Is there a way to do open them simultaneously.
Thanks
Shashank
I would suggest two ways.
Run two threads. Call system() from each thread.
Create a child process using fork() and run system() from both parent and child processes.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I am creating user programs that access a device driver.
Multiple threads must open the device? (each thread has a file descriptor of the device itself). Or can be opened from the principal and all the threads get a copy of the file descriptor?
What happens to the atomicity in access to the device?
A thread in Linux as a process is created via the system call clone. From its documentation :
If CLONE_FILES is set, the calling process and the child
process share the same file descriptor table. Any file
descriptor created by the calling process or by the child
process is also valid in the other process. Similarly, if one
of the processes closes a file descriptor, or changes its
associated flags (using the fcntl(2) F_SETFD operation), the
other process is also affected.
If CLONE_FILES is not set, the child process inherits a copy
of all file descriptors opened in the calling process at the
time of clone(). (The duplicated file descriptors in the
child refer to the same open file descriptions (see open(2))
as the corresponding file descriptors in the calling process.)
Subsequent operations that open or close file descriptors, or
change file descriptor flags, performed by either the calling
process or the child process do not affect the other process.
Assuming that you are using a library to create a thread like pthread. Threads created with pthread_create share the file descriptors with all other threads in the process (not just the parent). This cannot be changed. While process created with fork get a copy of the file descriptor. You must notice that sharing a file descriptor and having a copy are two different things. If you have a copy ( for example created with fork) then all copies must be closed before the file handler is definitely closed. If a file descriptor is shared among different threads, once one thread closes it, this file descriptor will be closed for all thread. Similarly, if one of the processes changes its associated flags (using the fcntl), the other process is also affected.