file-descriptor

Using the posix read() write() linux calls, is it guaranteed that if I write through one file descriptor and read through another file descriptor, in a serial fashion such that the two actions are mutually exclusive of each other... that my read file descriptor will always see what was written last by the write file descriptor? i believe this is the case, but I want to make sure and the man page isn't very helpful on this It depends on where you got the two file descriptors. If they come from a dup(2) call, then they share file offset and status, so doing a write(2) on one will affect the

I was going through a serial program and I observed that they use select() before using read() . Why exactly is this required. Why cant we just directly call read() and check if it fails or not ? Also why do we have to increment the file descriptor by 1 and pass it while I am passing the file descriptor set already to select() ? Example: r=select(fd+1, &fds, NULL, NULL, &timeout); where fds already has the value of fd The select() system call tells you whether there is any data to read on the file descriptors that you're interested in. Strictly, it is a question of whether a read operation on

(In BASH) I want a subshell to use a non-STDOUT non-STDERR file descriptor to pass some data back to the parent shell. How can I do that? Eventually I would love to save the data into some variable of the parent shell. ( # The following two lines show the behavior of the subshell. # We cannot change them. echo "This should go to STDOUT" echo "This is the data I want to pass to the parent shell" >&3 ) #... data_from_subshell=... # Somehow assign the value of &3 of the # subshell to this variable EDIT: The subshell runs a black-box program that writes to STDOUT and &3. Jan Hudec BEWARE, BASHISM

I am implementing the (ls) command on Unix while learning from a book. During the coding part of my implementation of the (ls) command with the (-l) flag , I see that I have to prompt the user and group names of the file. So far I have the user and group IDs from the following lines: struct stat statBuf; statBuf.st_uid; //For the user id. statBuf.st_gid; //For the group id. In the default (ls) command on Unix, the information of the file is printed in such a way that the user name is shown instead of the user id. Can anyone help me to find the correct methodology to retrieve the user and group

What is the windows equivalent of the unix command " ulimit -n" ? Basically, i want to set the maximum fd limit via command prompt. hmm... I may have been wrong before - setmaxstdio (see here ) - but it is per-process, not system wide. I may be wrong, but I didn't think there was a limit to set in Windows... but unless you can say how this relates to programming, I expect this answer will be closed soon. If you are in the "IT Pro" area (rather than development), then there is a sister-site, serverfault.com - coming soon for this type of question. I don't believe that current Windows O/S have a

What would happen if you call read (or write , or both) in two different thread, on the same file descriptor (lets says we are interested about a local file, and a it's a socket file descriptor), without using explicitly a synchronization mechanism? Read and Write are syscall, so, on a single core CPU, it's probably unlucky that two read would be executed "at the same time". But with multiple cores... What the linux kernel will do? And let's be a bit more general : is the behavior always the same for other kernels (like BSDs) ? Edit : According to the close documentation , we should be sure

Having more than one process read from a serial device (/dev/ttyXX) makes it so that both processes can't get all of the data -- the data will be split between them in some way. I'd like to write a program that reads from a serial device, creates several master/slave pty pairs, and then allows programs that were made to read from the serial device to instead read from the ptys so that all reading processes receive the data from the serial device and have the ptys act like the serial device in the sense that when they start reading from the pty they get only the most recent data. In other words