Windows and OS/2 have the notion of a shared file handle, so you can still do that if you like but the default is exclusive.
Cheers
Phil Hobbs
Windows and OS/2 have the notion of a shared file handle, so you can still do that if you like but the default is exclusive.
Cheers
Phil Hobbs
-- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
Even in a single process and with a normal diskfile it can be useful to have the file open multiple times (on different fd) e.g. to read it at one position and write it at another position without having to seek between te positions all the time. (a single fd has a single read/write position)
This can be done in the same thread or in different threads in the same process. Having threads in the process can be another reason to want to open it several times, so you don't have to needlessly interlock the threads to share the access to the file. (e.g. when one thread reads and another thread writes the same file at a different position)
Yup. The whole Unix file-descriptor-and-process model accomodates this, in several ways.
Consider the whole function of dup() - take an existing file descriptor, and "clone" it into a different and independent file descriptor while leaving the first one open.
Consider fork(), which spawns off a separate child process, and clones _all_ of the existing file descriptors from the parent process into the child.
Neither of these is (technically) "opening" the file more than once within a single process... in both cases you only call open() once... but they all have a similar effect, of providing two or more independent access paths to a single underlying file.
Unix/Linux/POSIX would be a very different beast, if these APIs didn't work that way.
The knowledgeable POSIX programmer is expected to be aware of these things, and either (1) not use them when not needed, (2) be aware of the need to close() descriptors you don't need, or (3) use them appropriately with the proper safeguards e.g. locks and semaphores and mutexes and so forth.
No different than working with a propane torch, or a soldering iron, or a hacksaw, or a hammer. You have to know which end to grab and which end not to grab :-)
Gerhard Hoffmann wrote in news:frhov6F16q0U1 @mid.individual.net:
Billy was there too.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.