1 @node Low-Level I/O, File System Interface, I/O on Streams, Top
2 @c %MENU% Low-level, less portable I/O
3 @chapter Low-Level Input/Output
5 This chapter describes functions for performing low-level input/output
6 operations on file descriptors. These functions include the primitives
7 for the higher-level I/O functions described in @ref{I/O on Streams}, as
8 well as functions for performing low-level control operations for which
9 there are no equivalents on streams.
11 Stream-level I/O is more flexible and usually more convenient;
12 therefore, programmers generally use the descriptor-level functions only
13 when necessary. These are some of the usual reasons:
17 For reading binary files in large chunks.
20 For reading an entire file into core before parsing it.
23 To perform operations other than data transfer, which can only be done
24 with a descriptor. (You can use @code{fileno} to get the descriptor
25 corresponding to a stream.)
28 To pass descriptors to a child process. (The child can create its own
29 stream to use a descriptor that it inherits, but cannot inherit a stream
34 * Opening and Closing Files:: How to open and close file
36 * I/O Primitives:: Reading and writing data.
37 * File Position Primitive:: Setting a descriptor's file
39 * Descriptors and Streams:: Converting descriptor to stream
41 * Stream/Descriptor Precautions:: Precautions needed if you use both
42 descriptors and streams.
43 * Scatter-Gather:: Fast I/O to discontinuous buffers.
44 * Copying File Data:: Copying data between files.
45 * Memory-mapped I/O:: Using files like memory.
46 * Waiting for I/O:: How to check for input or output
47 on multiple file descriptors.
48 * Synchronizing I/O:: Making sure all I/O actions completed.
49 * Asynchronous I/O:: Perform I/O in parallel.
50 * Control Operations:: Various other operations on file
52 * Duplicating Descriptors:: Fcntl commands for duplicating
54 * Descriptor Flags:: Fcntl commands for manipulating
55 flags associated with file
57 * File Status Flags:: Fcntl commands for manipulating
58 flags associated with open files.
59 * File Locks:: Fcntl commands for implementing
61 * Open File Description Locks:: Fcntl commands for implementing
62 open file description locking.
63 * Open File Description Locks Example:: An example of open file description lock
65 * Interrupt Input:: Getting an asynchronous signal when
67 * IOCTLs:: Generic I/O Control operations.
68 * Other Low-Level I/O APIs:: Other low-level-I/O-related functions.
72 @node Opening and Closing Files
73 @section Opening and Closing Files
75 @cindex opening a file descriptor
76 @cindex closing a file descriptor
77 This section describes the primitives for opening and closing files
78 using file descriptors. The @code{open} and @code{creat} functions are
79 declared in the header file @file{fcntl.h}, while @code{close} is
80 declared in @file{unistd.h}.
84 @deftypefun int open (const char *@var{filename}, int @var{flags}[, mode_t @var{mode}])
85 @standards{POSIX.1, fcntl.h}
86 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{@acsfd{}}}
87 The @code{open} function creates and returns a new file descriptor for
88 the file named by @var{filename}. Initially, the file position
89 indicator for the file is at the beginning of the file. The argument
90 @var{mode} (@pxref{Permission Bits}) is used only when a file is
91 created, but it doesn't hurt to supply the argument in any case.
93 The @var{flags} argument controls how the file is to be opened. This is
94 a bit mask; you create the value by the bitwise OR of the appropriate
95 parameters (using the @samp{|} operator in C).
96 @xref{File Status Flags}, for the parameters available.
98 The normal return value from @code{open} is a non-negative integer file
99 descriptor. In the case of an error, a value of @math{-1} is returned
100 instead. In addition to the usual file name errors (@pxref{File
101 Name Errors}), the following @code{errno} error conditions are defined
106 The file exists but is not readable/writable as requested by the @var{flags}
107 argument, or the file does not exist and the directory is unwritable so
108 it cannot be created.
111 Both @code{O_CREAT} and @code{O_EXCL} are set, and the named file already
115 The @code{open} operation was interrupted by a signal.
116 @xref{Interrupted Primitives}.
119 The @var{flags} argument specified write access, and the file is a directory.
122 The process has too many files open.
123 The maximum number of file descriptors is controlled by the
124 @code{RLIMIT_NOFILE} resource limit; @pxref{Limits on Resources}.
127 The entire system, or perhaps the file system which contains the
128 directory, cannot support any additional open files at the moment.
129 (This problem cannot happen on @gnuhurdsystems{}.)
132 The named file does not exist, and @code{O_CREAT} is not specified.
135 The directory or file system that would contain the new file cannot be
136 extended, because there is no disk space left.
139 @code{O_NONBLOCK} and @code{O_WRONLY} are both set in the @var{flags}
140 argument, the file named by @var{filename} is a FIFO (@pxref{Pipes and
141 FIFOs}), and no process has the file open for reading.
144 The file resides on a read-only file system and any of @w{@code{O_WRONLY}},
145 @code{O_RDWR}, and @code{O_TRUNC} are set in the @var{flags} argument,
146 or @code{O_CREAT} is set and the file does not already exist.
151 If on a 32 bit machine the sources are translated with
152 @code{_FILE_OFFSET_BITS == 64} the function @code{open} returns a file
153 descriptor opened in the large file mode which enables the file handling
154 functions to use files up to @twoexp{63} bytes in size and offset from
155 @minus{}@twoexp{63} to @twoexp{63}. This happens transparently for the user
156 since all of the low-level file handling functions are equally replaced.
158 This function is a cancellation point in multi-threaded programs. This
159 is a problem if the thread allocates some resources (like memory, file
160 descriptors, semaphores or whatever) at the time @code{open} is
161 called. If the thread gets canceled these resources stay allocated
162 until the program ends. To avoid this calls to @code{open} should be
163 protected using cancellation handlers.
164 @c ref pthread_cleanup_push / pthread_cleanup_pop
166 The @code{open} function is the underlying primitive for the @code{fopen}
167 and @code{freopen} functions, that create streams.
170 @deftypefun int open64 (const char *@var{filename}, int @var{flags}[, mode_t @var{mode}])
171 @standards{Unix98, fcntl.h}
172 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{@acsfd{}}}
173 This function is similar to @code{open}. It returns a file descriptor
174 which can be used to access the file named by @var{filename}. The only
175 difference is that on 32 bit systems the file is opened in the
176 large file mode. I.e., file length and file offsets can exceed 31 bits.
178 When the sources are translated with @code{_FILE_OFFSET_BITS == 64} this
179 function is actually available under the name @code{open}. I.e., the
180 new, extended API using 64 bit file sizes and offsets transparently
181 replaces the old API.
184 @deftypefun int openat (int @var{filedes}, const char *@var{filename}, int @var{flags}[, mode_t @var{mode}])
185 @standards{POSIX.1, fcntl.h}
186 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{@acsfd{}}}
187 This function is the descriptor-relative variant of the @code{open}
188 function. @xref{Descriptor-Relative Access}.
190 Note that the @var{flags} argument of @code{openat} does not accept
191 @code{AT_@dots{}} flags, only the flags described for the @code{open}
194 The @code{openat} function can fail for additional reasons:
198 The @var{filedes} argument is not a valid file descriptor.
201 The descriptor @var{filedes} is not associated with a directory, and
202 @var{filename} is a relative file name.
205 When the sources are compiled with @code{_FILE_OFFSET_BITS == 64} this
206 function is in fact @code{openat64} since the LFS interface transparently
207 replaces the normal implementation.
210 @deftypefun int openat64 (int @var{filedes}, const char *@var{filename}, int @var{flags}[, mode_t @var{mode}])
211 @standards{GNU, fcntl.h}
212 The large-file variant of the @code{openat}, similar to how
213 @code{open64} is the large-file variant of @code{open}.
215 When the sources are translated with @code{_FILE_OFFSET_BITS == 64} this
216 function is actually available under the name @code{openat}. I.e., the
217 new, extended API using 64 bit file sizes and offsets transparently
218 replaces the old API.
221 @deftypefn {Obsolete function} int creat (const char *@var{filename}, mode_t @var{mode})
222 @standards{POSIX.1, fcntl.h}
223 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{@acsfd{}}}
224 This function is obsolete. The call:
227 creat (@var{filename}, @var{mode})
234 open (@var{filename}, O_WRONLY | O_CREAT | O_TRUNC, @var{mode})
237 If on a 32 bit machine the sources are translated with
238 @code{_FILE_OFFSET_BITS == 64} the function @code{creat} returns a file
239 descriptor opened in the large file mode which enables the file handling
240 functions to use files up to @twoexp{63} in size and offset from
241 @minus{}@twoexp{63} to @twoexp{63}. This happens transparently for the user
242 since all of the low-level file handling functions are equally replaced.
245 @deftypefn {Obsolete function} int creat64 (const char *@var{filename}, mode_t @var{mode})
246 @standards{Unix98, fcntl.h}
247 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{@acsfd{}}}
248 This function is similar to @code{creat}. It returns a file descriptor
249 which can be used to access the file named by @var{filename}. The only
250 difference is that on 32 bit systems the file is opened in the
251 large file mode. I.e., file length and file offsets can exceed 31 bits.
253 To use this file descriptor one must not use the normal operations but
254 instead the counterparts named @code{*64}, e.g., @code{read64}.
256 When the sources are translated with @code{_FILE_OFFSET_BITS == 64} this
257 function is actually available under the name @code{open}. I.e., the
258 new, extended API using 64 bit file sizes and offsets transparently
259 replaces the old API.
262 @deftypefun int close (int @var{filedes})
263 @standards{POSIX.1, unistd.h}
264 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{@acsfd{}}}
265 The function @code{close} closes the file descriptor @var{filedes}.
266 Closing a file has the following consequences:
270 The file descriptor is deallocated.
273 Any record locks owned by the process on the file are unlocked.
276 When all file descriptors associated with a pipe or FIFO have been closed,
277 any unread data is discarded.
280 This function is a cancellation point in multi-threaded programs. This
281 is a problem if the thread allocates some resources (like memory, file
282 descriptors, semaphores or whatever) at the time @code{close} is
283 called. If the thread gets canceled these resources stay allocated
284 until the program ends. To avoid this, calls to @code{close} should be
285 protected using cancellation handlers.
286 @c ref pthread_cleanup_push / pthread_cleanup_pop
288 The normal return value from @code{close} is @math{0}; a value of @math{-1}
289 is returned in case of failure. The following @code{errno} error
290 conditions are defined for this function:
294 The @var{filedes} argument is not a valid file descriptor.
297 The @code{close} call was interrupted by a signal.
298 @xref{Interrupted Primitives}.
299 Here is an example of how to handle @code{EINTR} properly:
302 TEMP_FAILURE_RETRY (close (desc));
308 When the file is accessed by NFS, these errors from @code{write} can sometimes
309 not be detected until @code{close}. @xref{I/O Primitives}, for details
313 Please note that there is @emph{no} separate @code{close64} function.
314 This is not necessary since this function does not determine nor depend
315 on the mode of the file. The kernel which performs the @code{close}
316 operation knows which mode the descriptor is used for and can handle
320 To close a stream, call @code{fclose} (@pxref{Closing Streams}) instead
321 of trying to close its underlying file descriptor with @code{close}.
322 This flushes any buffered output and updates the stream object to
323 indicate that it is closed.
325 @deftypefun int close_range (unsigned int @var{lowfd}, unsigned int @var{maxfd}, int @var{flags})
326 @standards{Linux, unistd.h}
327 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{@acsfd{}}}
328 @c This is a syscall for Linux v5.9. There is no fallback emulation for
331 The function @code{close_range} closes the file descriptor from @var{lowfd}
332 to @var{maxfd} (inclusive). This function is similar to call @code{close} in
333 specified file descriptor range depending on the @var{flags}.
335 This is function is only supported on recent Linux versions and @theglibc{}
336 does not provide any fallback (the application will need to handle possible
339 The @var{flags} add options on how the files are closes. Linux currently
343 @item CLOSE_RANGE_UNSHARE
344 Unshare the file descriptor table before closing file descriptors.
346 @item CLOSE_RANGE_CLOEXEC
347 Set the @code{FD_CLOEXEC} bit instead of closing the file descriptor.
350 The normal return value from @code{close_range} is @math{0}; a value
351 of @math{-1} is returned in case of failure. The following @code{errno} error
352 conditions are defined for this function:
356 The @var{lowfd} value is larger than @var{maxfd} or an unsupported @var{flags}
360 Either there is not enough memory for the operation, or the process is
361 out of address space. It can only happen when @code{CLOSE_RANGE_UNSHARED}
365 The process has too many files open and it can only happens when
366 @code{CLOSE_RANGE_UNSHARED} flag is used.
367 The maximum number of file descriptors is controlled by the
368 @code{RLIMIT_NOFILE} resource limit; @pxref{Limits on Resources}.
371 The kernel does not implement the required functionality.
375 @deftypefun void closefrom (int @var{lowfd})
376 @standards{GNU, unistd.h}
377 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{@acsfd{}}}
379 The function @code{closefrom} closes all file descriptors greater than or equal
380 to @var{lowfd}. This function is similar to calling
381 @code{close} for all open file descriptors not less than @var{lowfd}.
383 Already closed file descriptors are ignored.
387 @section Input and Output Primitives
389 This section describes the functions for performing primitive input and
390 output operations on file descriptors: @code{read}, @code{write}, and
391 @code{lseek}. These functions are declared in the header file
395 @deftp {Data Type} ssize_t
396 @standards{POSIX.1, unistd.h}
397 This data type is used to represent the sizes of blocks that can be
398 read or written in a single operation. It is similar to @code{size_t},
399 but must be a signed type.
402 @cindex reading from a file descriptor
403 @deftypefun ssize_t read (int @var{filedes}, void *@var{buffer}, size_t @var{size})
404 @standards{POSIX.1, unistd.h}
405 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
406 The @code{read} function reads up to @var{size} bytes from the file
407 with descriptor @var{filedes}, storing the results in the @var{buffer}.
408 (This is not necessarily a character string, and no terminating null
411 @cindex end-of-file, on a file descriptor
412 The return value is the number of bytes actually read. This might be
413 less than @var{size}; for example, if there aren't that many bytes left
414 in the file or if there aren't that many bytes immediately available.
415 The exact behavior depends on what kind of file it is. Note that
416 reading less than @var{size} bytes is not an error.
418 A value of zero indicates end-of-file (except if the value of the
419 @var{size} argument is also zero). This is not considered an error.
420 If you keep calling @code{read} while at end-of-file, it will keep
421 returning zero and doing nothing else.
423 If @code{read} returns at least one character, there is no way you can
424 tell whether end-of-file was reached. But if you did reach the end, the
425 next read will return zero.
427 In case of an error, @code{read} returns @math{-1}. The following
428 @code{errno} error conditions are defined for this function:
432 Normally, when no input is immediately available, @code{read} waits for
433 some input. But if the @code{O_NONBLOCK} flag is set for the file
434 (@pxref{File Status Flags}), @code{read} returns immediately without
435 reading any data, and reports this error.
437 @strong{Compatibility Note:} Most versions of BSD Unix use a different
438 error code for this: @code{EWOULDBLOCK}. In @theglibc{},
439 @code{EWOULDBLOCK} is an alias for @code{EAGAIN}, so it doesn't matter
442 On some systems, reading a large amount of data from a character special
443 file can also fail with @code{EAGAIN} if the kernel cannot find enough
444 physical memory to lock down the user's pages. This is limited to
445 devices that transfer with direct memory access into the user's memory,
446 which means it does not include terminals, since they always use
447 separate buffers inside the kernel. This problem never happens on
450 Any condition that could result in @code{EAGAIN} can instead result in a
451 successful @code{read} which returns fewer bytes than requested.
452 Calling @code{read} again immediately would result in @code{EAGAIN}.
455 The @var{filedes} argument is not a valid file descriptor,
456 or is not open for reading.
459 @code{read} was interrupted by a signal while it was waiting for input.
460 @xref{Interrupted Primitives}. A signal will not necessarily cause
461 @code{read} to return @code{EINTR}; it may instead result in a
462 successful @code{read} which returns fewer bytes than requested.
465 For many devices, and for disk files, this error code indicates
468 @code{EIO} also occurs when a background process tries to read from the
469 controlling terminal, and the normal action of stopping the process by
470 sending it a @code{SIGTTIN} signal isn't working. This might happen if
471 the signal is being blocked or ignored, or because the process group is
472 orphaned. @xref{Job Control}, for more information about job control,
473 and @ref{Signal Handling}, for information about signals.
476 In some systems, when reading from a character or block device, position
477 and size offsets must be aligned to a particular block size. This error
478 indicates that the offsets were not properly aligned.
481 Please note that there is no function named @code{read64}. This is not
482 necessary since this function does not directly modify or handle the
483 possibly wide file offset. Since the kernel handles this state
484 internally, the @code{read} function can be used for all cases.
486 This function is a cancellation point in multi-threaded programs. This
487 is a problem if the thread allocates some resources (like memory, file
488 descriptors, semaphores or whatever) at the time @code{read} is
489 called. If the thread gets canceled these resources stay allocated
490 until the program ends. To avoid this, calls to @code{read} should be
491 protected using cancellation handlers.
492 @c ref pthread_cleanup_push / pthread_cleanup_pop
494 The @code{read} function is the underlying primitive for all of the
495 functions that read from streams, such as @code{fgetc}.
498 @deftypefun ssize_t pread (int @var{filedes}, void *@var{buffer}, size_t @var{size}, off_t @var{offset})
499 @standards{Unix98, unistd.h}
500 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
501 @c This is usually a safe syscall. The sysdeps/posix fallback emulation
502 @c is not MT-Safe because it uses lseek, read and lseek back, but is it
504 The @code{pread} function is similar to the @code{read} function. The
505 first three arguments are identical, and the return values and error
506 codes also correspond.
508 The difference is the fourth argument and its handling. The data block
509 is not read from the current position of the file descriptor
510 @code{filedes}. Instead the data is read from the file starting at
511 position @var{offset}. The position of the file descriptor itself is
512 not affected by the operation. The value is the same as before the call.
514 When the source file is compiled with @code{_FILE_OFFSET_BITS == 64} the
515 @code{pread} function is in fact @code{pread64} and the type
516 @code{off_t} has 64 bits, which makes it possible to handle files up to
517 @twoexp{63} bytes in length.
519 The return value of @code{pread} describes the number of bytes read.
520 In the error case it returns @math{-1} like @code{read} does and the
521 error codes are also the same, with these additions:
525 The value given for @var{offset} is negative and therefore illegal.
528 The file descriptor @var{filedes} is associated with a pipe or a FIFO and
529 this device does not allow positioning of the file pointer.
532 The function is an extension defined in the Unix Single Specification
536 @deftypefun ssize_t pread64 (int @var{filedes}, void *@var{buffer}, size_t @var{size}, off64_t @var{offset})
537 @standards{Unix98, unistd.h}
538 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
539 @c This is usually a safe syscall. The sysdeps/posix fallback emulation
540 @c is not MT-Safe because it uses lseek64, read and lseek64 back, but is
542 This function is similar to the @code{pread} function. The difference
543 is that the @var{offset} parameter is of type @code{off64_t} instead of
544 @code{off_t} which makes it possible on 32 bit machines to address
545 files larger than @twoexp{31} bytes and up to @twoexp{63} bytes. The
546 file descriptor @code{filedes} must be opened using @code{open64} since
547 otherwise the large offsets possible with @code{off64_t} will lead to
548 errors with a descriptor in small file mode.
550 When the source file is compiled with @code{_FILE_OFFSET_BITS == 64} on a
551 32 bit machine this function is actually available under the name
552 @code{pread} and so transparently replaces the 32 bit interface.
555 @cindex writing to a file descriptor
556 @deftypefun ssize_t write (int @var{filedes}, const void *@var{buffer}, size_t @var{size})
557 @standards{POSIX.1, unistd.h}
558 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
559 @c Some say write is thread-unsafe on Linux without O_APPEND. In the VFS layer
560 @c the vfs_write() does no locking around the acquisition of a file offset and
561 @c therefore multiple threads / kernel tasks may race and get the same offset
562 @c resulting in data loss.
565 @c http://thread.gmane.org/gmane.linux.kernel/397980
566 @c http://lwn.net/Articles/180387/
568 @c The counter argument is that POSIX only says that the write starts at the
569 @c file position and that the file position is updated *before* the function
570 @c returns. What that really means is that any expectation of atomic writes is
571 @c strictly an invention of the interpretation of the reader. Data loss could
572 @c happen if two threads start the write at the same time. Only writes that
573 @c come after the return of another write are guaranteed to follow the other
576 @c The other side of the coin is that POSIX goes on further to say in
577 @c "2.9.7 Thread Interactions with Regular File Operations" that threads
578 @c should never see interleaving sets of file operations, but it is insane
579 @c to do anything like that because it kills performance, so you don't get
580 @c those guarantees in Linux.
582 @c So we mark it thread safe, it doesn't blow up, but you might loose
583 @c data, and we don't strictly meet the POSIX requirements.
585 @c The fix for file offsets racing was merged in 3.14, the commits were:
586 @c 9c225f2655e36a470c4f58dbbc99244c5fc7f2d4, and
587 @c d7a15f8d0777955986a2ab00ab181795cab14b01. Therefore after Linux 3.14 you
588 @c should get mostly MT-safe writes.
589 The @code{write} function writes up to @var{size} bytes from
590 @var{buffer} to the file with descriptor @var{filedes}. The data in
591 @var{buffer} is not necessarily a character string and a null character is
592 output like any other character.
594 The return value is the number of bytes actually written. This may be
595 @var{size}, but can always be smaller. Your program should always call
596 @code{write} in a loop, iterating until all the data is written.
598 Once @code{write} returns, the data is enqueued to be written and can be
599 read back right away, but it is not necessarily written out to permanent
600 storage immediately. You can use @code{fsync} when you need to be sure
601 your data has been permanently stored before continuing. (It is more
602 efficient for the system to batch up consecutive writes and do them all
603 at once when convenient. Normally they will always be written to disk
604 within a minute or less.) Modern systems provide another function
605 @code{fdatasync} which guarantees integrity only for the file data and
607 @c !!! xref fsync, fdatasync
608 You can use the @code{O_FSYNC} open mode to make @code{write} always
609 store the data to disk before returning; @pxref{Operating Modes}.
611 In the case of an error, @code{write} returns @math{-1}. The following
612 @code{errno} error conditions are defined for this function:
616 Normally, @code{write} blocks until the write operation is complete.
617 But if the @code{O_NONBLOCK} flag is set for the file (@pxref{Control
618 Operations}), it returns immediately without writing any data and
619 reports this error. An example of a situation that might cause the
620 process to block on output is writing to a terminal device that supports
621 flow control, where output has been suspended by receipt of a STOP
624 @strong{Compatibility Note:} Most versions of BSD Unix use a different
625 error code for this: @code{EWOULDBLOCK}. In @theglibc{},
626 @code{EWOULDBLOCK} is an alias for @code{EAGAIN}, so it doesn't matter
629 On some systems, writing a large amount of data from a character special
630 file can also fail with @code{EAGAIN} if the kernel cannot find enough
631 physical memory to lock down the user's pages. This is limited to
632 devices that transfer with direct memory access into the user's memory,
633 which means it does not include terminals, since they always use
634 separate buffers inside the kernel. This problem does not arise on
638 The @var{filedes} argument is not a valid file descriptor,
639 or is not open for writing.
642 The size of the file would become larger than the implementation can support.
645 The @code{write} operation was interrupted by a signal while it was
646 blocked waiting for completion. A signal will not necessarily cause
647 @code{write} to return @code{EINTR}; it may instead result in a
648 successful @code{write} which writes fewer bytes than requested.
649 @xref{Interrupted Primitives}.
652 For many devices, and for disk files, this error code indicates
656 The device containing the file is full.
659 This error is returned when you try to write to a pipe or FIFO that
660 isn't open for reading by any process. When this happens, a @code{SIGPIPE}
661 signal is also sent to the process; see @ref{Signal Handling}.
664 In some systems, when writing to a character or block device, position
665 and size offsets must be aligned to a particular block size. This error
666 indicates that the offsets were not properly aligned.
669 Unless you have arranged to prevent @code{EINTR} failures, you should
670 check @code{errno} after each failing call to @code{write}, and if the
671 error was @code{EINTR}, you should simply repeat the call.
672 @xref{Interrupted Primitives}. The easy way to do this is with the
673 macro @code{TEMP_FAILURE_RETRY}, as follows:
676 nbytes = TEMP_FAILURE_RETRY (write (desc, buffer, count));
679 Please note that there is no function named @code{write64}. This is not
680 necessary since this function does not directly modify or handle the
681 possibly wide file offset. Since the kernel handles this state
682 internally the @code{write} function can be used for all cases.
684 This function is a cancellation point in multi-threaded programs. This
685 is a problem if the thread allocates some resources (like memory, file
686 descriptors, semaphores or whatever) at the time @code{write} is
687 called. If the thread gets canceled these resources stay allocated
688 until the program ends. To avoid this, calls to @code{write} should be
689 protected using cancellation handlers.
690 @c ref pthread_cleanup_push / pthread_cleanup_pop
692 The @code{write} function is the underlying primitive for all of the
693 functions that write to streams, such as @code{fputc}.
696 @deftypefun ssize_t pwrite (int @var{filedes}, const void *@var{buffer}, size_t @var{size}, off_t @var{offset})
697 @standards{Unix98, unistd.h}
698 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
699 @c This is usually a safe syscall. The sysdeps/posix fallback emulation
700 @c is not MT-Safe because it uses lseek, write and lseek back, but is it
702 The @code{pwrite} function is similar to the @code{write} function. The
703 first three arguments are identical, and the return values and error codes
706 The difference is the fourth argument and its handling. The data block
707 is not written to the current position of the file descriptor
708 @code{filedes}. Instead the data is written to the file starting at
709 position @var{offset}. The position of the file descriptor itself is
710 not affected by the operation. The value is the same as before the call.
712 However, on Linux, if a file is opened with @code{O_APPEND}, @code{pwrite}
713 appends data to the end of the file, regardless of the value of
716 When the source file is compiled with @code{_FILE_OFFSET_BITS == 64} the
717 @code{pwrite} function is in fact @code{pwrite64} and the type
718 @code{off_t} has 64 bits, which makes it possible to handle files up to
719 @twoexp{63} bytes in length.
721 The return value of @code{pwrite} describes the number of written bytes.
722 In the error case it returns @math{-1} like @code{write} does and the
723 error codes are also the same, with these additions:
727 The value given for @var{offset} is negative and therefore illegal.
730 The file descriptor @var{filedes} is associated with a pipe or a FIFO and
731 this device does not allow positioning of the file pointer.
734 The function is an extension defined in the Unix Single Specification
738 @deftypefun ssize_t pwrite64 (int @var{filedes}, const void *@var{buffer}, size_t @var{size}, off64_t @var{offset})
739 @standards{Unix98, unistd.h}
740 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
741 @c This is usually a safe syscall. The sysdeps/posix fallback emulation
742 @c is not MT-Safe because it uses lseek64, write and lseek64 back, but
743 @c is it used anywhere?
744 This function is similar to the @code{pwrite} function. The difference
745 is that the @var{offset} parameter is of type @code{off64_t} instead of
746 @code{off_t} which makes it possible on 32 bit machines to address
747 files larger than @twoexp{31} bytes and up to @twoexp{63} bytes. The
748 file descriptor @code{filedes} must be opened using @code{open64} since
749 otherwise the large offsets possible with @code{off64_t} will lead to
750 errors with a descriptor in small file mode.
752 When the source file is compiled using @code{_FILE_OFFSET_BITS == 64} on a
753 32 bit machine this function is actually available under the name
754 @code{pwrite} and so transparently replaces the 32 bit interface.
757 @node File Position Primitive
758 @section Setting the File Position of a Descriptor
760 Just as you can set the file position of a stream with @code{fseek}, you
761 can set the file position of a descriptor with @code{lseek}. This
762 specifies the position in the file for the next @code{read} or
763 @code{write} operation. @xref{File Positioning}, for more information
764 on the file position and what it means.
766 To read the current file position value from a descriptor, use
767 @code{lseek (@var{desc}, 0, SEEK_CUR)}.
769 @cindex file positioning on a file descriptor
770 @cindex positioning a file descriptor
771 @cindex seeking on a file descriptor
772 @deftypefun off_t lseek (int @var{filedes}, off_t @var{offset}, int @var{whence})
773 @standards{POSIX.1, unistd.h}
774 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
775 The @code{lseek} function is used to change the file position of the
776 file with descriptor @var{filedes}.
778 The @var{whence} argument specifies how the @var{offset} should be
779 interpreted, in the same way as for the @code{fseek} function, and it must
780 be one of the symbolic constants @code{SEEK_SET}, @code{SEEK_CUR}, or
785 Specifies that @var{offset} is a count of characters from the beginning
789 Specifies that @var{offset} is a count of characters from the current
790 file position. This count may be positive or negative.
793 Specifies that @var{offset} is a count of characters from the end of
794 the file. A negative count specifies a position within the current
795 extent of the file; a positive count specifies a position past the
796 current end. If you set the position past the current end, and
797 actually write data, you will extend the file with zeros up to that
801 The return value from @code{lseek} is normally the resulting file
802 position, measured in bytes from the beginning of the file.
803 You can use this feature together with @code{SEEK_CUR} to read the
804 current file position.
806 If you want to append to the file, setting the file position to the
807 current end of file with @code{SEEK_END} is not sufficient. Another
808 process may write more data after you seek but before you write,
809 extending the file so the position you write onto clobbers their data.
810 Instead, use the @code{O_APPEND} operating mode; @pxref{Operating Modes}.
812 You can set the file position past the current end of the file. This
813 does not by itself make the file longer; @code{lseek} never changes the
814 file. But subsequent output at that position will extend the file.
815 Characters between the previous end of file and the new position are
816 filled with zeros. Extending the file in this way can create a
817 ``hole'': the blocks of zeros are not actually allocated on disk, so the
818 file takes up less space than it appears to; it is then called a
821 @cindex holes in files
823 If the file position cannot be changed, or the operation is in some way
824 invalid, @code{lseek} returns a value of @math{-1}. The following
825 @code{errno} error conditions are defined for this function:
829 The @var{filedes} is not a valid file descriptor.
832 The @var{whence} argument value is not valid, or the resulting
833 file offset is not valid. A file offset is invalid.
836 The @var{filedes} corresponds to an object that cannot be positioned,
837 such as a pipe, FIFO or terminal device. (POSIX.1 specifies this error
838 only for pipes and FIFOs, but on @gnusystems{}, you always get
839 @code{ESPIPE} if the object is not seekable.)
842 When the source file is compiled with @code{_FILE_OFFSET_BITS == 64} the
843 @code{lseek} function is in fact @code{lseek64} and the type
844 @code{off_t} has 64 bits which makes it possible to handle files up to
845 @twoexp{63} bytes in length.
847 This function is a cancellation point in multi-threaded programs. This
848 is a problem if the thread allocates some resources (like memory, file
849 descriptors, semaphores or whatever) at the time @code{lseek} is
850 called. If the thread gets canceled these resources stay allocated
851 until the program ends. To avoid this calls to @code{lseek} should be
852 protected using cancellation handlers.
853 @c ref pthread_cleanup_push / pthread_cleanup_pop
855 The @code{lseek} function is the underlying primitive for the
856 @code{fseek}, @code{fseeko}, @code{ftell}, @code{ftello} and
857 @code{rewind} functions, which operate on streams instead of file
861 @deftypefun off64_t lseek64 (int @var{filedes}, off64_t @var{offset}, int @var{whence})
862 @standards{Unix98, unistd.h}
863 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
864 This function is similar to the @code{lseek} function. The difference
865 is that the @var{offset} parameter is of type @code{off64_t} instead of
866 @code{off_t} which makes it possible on 32 bit machines to address
867 files larger than @twoexp{31} bytes and up to @twoexp{63} bytes. The
868 file descriptor @code{filedes} must be opened using @code{open64} since
869 otherwise the large offsets possible with @code{off64_t} will lead to
870 errors with a descriptor in small file mode.
872 When the source file is compiled with @code{_FILE_OFFSET_BITS == 64} on a
873 32 bits machine this function is actually available under the name
874 @code{lseek} and so transparently replaces the 32 bit interface.
877 You can have multiple descriptors for the same file if you open the file
878 more than once, or if you duplicate a descriptor with @code{dup}.
879 Descriptors that come from separate calls to @code{open} have independent
880 file positions; using @code{lseek} on one descriptor has no effect on the
888 d1 = open ("foo", O_RDONLY);
889 d2 = open ("foo", O_RDONLY);
890 lseek (d1, 1024, SEEK_SET);
897 will read the first four characters of the file @file{foo}. (The
898 error-checking code necessary for a real program has been omitted here
901 By contrast, descriptors made by duplication share a common file
902 position with the original descriptor that was duplicated. Anything
903 which alters the file position of one of the duplicates, including
904 reading or writing data, affects all of them alike. Thus, for example,
909 char buf1[4], buf2[4];
910 d1 = open ("foo", O_RDONLY);
913 lseek (d3, 1024, SEEK_SET);
920 will read four characters starting with the 1024'th character of
921 @file{foo}, and then four more characters starting with the 1028'th
924 @deftp {Data Type} off_t
925 @standards{POSIX.1, sys/types.h}
926 This is a signed integer type used to represent file sizes. In
927 @theglibc{}, this type is no narrower than @code{int}.
929 If the source is compiled with @code{_FILE_OFFSET_BITS == 64} this type
930 is transparently replaced by @code{off64_t}.
933 @deftp {Data Type} off64_t
934 @standards{Unix98, sys/types.h}
935 This type is used similar to @code{off_t}. The difference is that even
936 on 32 bit machines, where the @code{off_t} type would have 32 bits,
937 @code{off64_t} has 64 bits and so is able to address files up to
938 @twoexp{63} bytes in length.
940 When compiling with @code{_FILE_OFFSET_BITS == 64} this type is
941 available under the name @code{off_t}.
944 These aliases for the @samp{SEEK_@dots{}} constants exist for the sake
945 of compatibility with older BSD systems. They are defined in two
946 different header files: @file{fcntl.h} and @file{sys/file.h}.
950 An alias for @code{SEEK_SET}.
953 An alias for @code{SEEK_CUR}.
956 An alias for @code{SEEK_END}.
959 @node Descriptors and Streams
960 @section Descriptors and Streams
961 @cindex streams, and file descriptors
962 @cindex converting file descriptor to stream
963 @cindex extracting file descriptor from stream
965 Given an open file descriptor, you can create a stream for it with the
966 @code{fdopen} function. You can get the underlying file descriptor for
967 an existing stream with the @code{fileno} function. These functions are
968 declared in the header file @file{stdio.h}.
971 @deftypefun {FILE *} fdopen (int @var{filedes}, const char *@var{opentype})
972 @standards{POSIX.1, stdio.h}
973 @safety{@prelim{}@mtsafe{}@asunsafe{@ascuheap{} @asulock{}}@acunsafe{@acsmem{} @aculock{}}}
974 The @code{fdopen} function returns a new stream for the file descriptor
977 The @var{opentype} argument is interpreted in the same way as for the
978 @code{fopen} function (@pxref{Opening Streams}), except that
979 the @samp{b} option is not permitted; this is because @gnusystems{} make no
980 distinction between text and binary files. Also, @code{"w"} and
981 @code{"w+"} do not cause truncation of the file; these have an effect only
982 when opening a file, and in this case the file has already been opened.
983 You must make sure that the @var{opentype} argument matches the actual
984 mode of the open file descriptor.
986 The return value is the new stream. If the stream cannot be created
987 (for example, if the modes for the file indicated by the file descriptor
988 do not permit the access specified by the @var{opentype} argument), a
989 null pointer is returned instead.
991 In some other systems, @code{fdopen} may fail to detect that the modes
992 for file descriptors do not permit the access specified by
993 @code{opentype}. @Theglibc{} always checks for this.
996 For an example showing the use of the @code{fdopen} function,
997 see @ref{Creating a Pipe}.
999 @deftypefun int fileno (FILE *@var{stream})
1000 @standards{POSIX.1, stdio.h}
1001 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1002 This function returns the file descriptor associated with the stream
1003 @var{stream}. If an error is detected (for example, if the @var{stream}
1004 is not valid) or if @var{stream} does not do I/O to a file,
1005 @code{fileno} returns @math{-1}.
1008 @deftypefun int fileno_unlocked (FILE *@var{stream})
1009 @standards{GNU, stdio.h}
1010 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1011 The @code{fileno_unlocked} function is equivalent to the @code{fileno}
1012 function except that it does not implicitly lock the stream if the state
1013 is @code{FSETLOCKING_INTERNAL}.
1015 This function is a GNU extension.
1018 @cindex standard file descriptors
1019 @cindex file descriptors, standard
1020 There are also symbolic constants defined in @file{unistd.h} for the
1021 file descriptors belonging to the standard streams @code{stdin},
1022 @code{stdout}, and @code{stderr}; see @ref{Standard Streams}.
1027 @standards{POSIX.1, unistd.h}
1028 This macro has value @code{0}, which is the file descriptor for
1030 @cindex standard input file descriptor
1033 @standards{POSIX.1, unistd.h}
1034 This macro has value @code{1}, which is the file descriptor for
1036 @cindex standard output file descriptor
1039 @standards{POSIX.1, unistd.h}
1040 This macro has value @code{2}, which is the file descriptor for
1041 standard error output.
1043 @cindex standard error file descriptor
1045 @node Stream/Descriptor Precautions
1046 @section Dangers of Mixing Streams and Descriptors
1048 @cindex streams and descriptors
1049 @cindex descriptors and streams
1050 @cindex mixing descriptors and streams
1052 You can have multiple file descriptors and streams (let's call both
1053 streams and descriptors ``channels'' for short) connected to the same
1054 file, but you must take care to avoid confusion between channels. There
1055 are two cases to consider: @dfn{linked} channels that share a single
1056 file position value, and @dfn{independent} channels that have their own
1059 It's best to use just one channel in your program for actual data
1060 transfer to any given file, except when all the access is for input.
1061 For example, if you open a pipe (something you can only do at the file
1062 descriptor level), either do all I/O with the descriptor, or construct a
1063 stream from the descriptor with @code{fdopen} and then do all I/O with
1067 * Linked Channels:: Dealing with channels sharing a file position.
1068 * Independent Channels:: Dealing with separately opened, unlinked channels.
1069 * Cleaning Streams:: Cleaning a stream makes it safe to use
1073 @node Linked Channels
1074 @subsection Linked Channels
1075 @cindex linked channels
1077 Channels that come from a single opening share the same file position;
1078 we call them @dfn{linked} channels. Linked channels result when you
1079 make a stream from a descriptor using @code{fdopen}, when you get a
1080 descriptor from a stream with @code{fileno}, when you copy a descriptor
1081 with @code{dup} or @code{dup2}, and when descriptors are inherited
1082 during @code{fork}. For files that don't support random access, such as
1083 terminals and pipes, @emph{all} channels are effectively linked. On
1084 random-access files, all append-type output streams are effectively
1085 linked to each other.
1087 @cindex cleaning up a stream
1088 If you have been using a stream for I/O (or have just opened the stream),
1089 and you want to do I/O using
1090 another channel (either a stream or a descriptor) that is linked to it,
1091 you must first @dfn{clean up} the stream that you have been using.
1092 @xref{Cleaning Streams}.
1094 Terminating a process, or executing a new program in the process,
1095 destroys all the streams in the process. If descriptors linked to these
1096 streams persist in other processes, their file positions become
1097 undefined as a result. To prevent this, you must clean up the streams
1098 before destroying them.
1100 @node Independent Channels
1101 @subsection Independent Channels
1102 @cindex independent channels
1104 When you open channels (streams or descriptors) separately on a seekable
1105 file, each channel has its own file position. These are called
1106 @dfn{independent channels}.
1108 The system handles each channel independently. Most of the time, this
1109 is quite predictable and natural (especially for input): each channel
1110 can read or write sequentially at its own place in the file. However,
1111 if some of the channels are streams, you must take these precautions:
1115 You should clean an output stream after use, before doing anything else
1116 that might read or write from the same part of the file.
1119 You should clean an input stream before reading data that may have been
1120 modified using an independent channel. Otherwise, you might read
1121 obsolete data that had been in the stream's buffer.
1124 If you do output to one channel at the end of the file, this will
1125 certainly leave the other independent channels positioned somewhere
1126 before the new end. You cannot reliably set their file positions to the
1127 new end of file before writing, because the file can always be extended
1128 by another process between when you set the file position and when you
1129 write the data. Instead, use an append-type descriptor or stream; they
1130 always output at the current end of the file. In order to make the
1131 end-of-file position accurate, you must clean the output channel you
1132 were using, if it is a stream.
1134 It's impossible for two channels to have separate file pointers for a
1135 file that doesn't support random access. Thus, channels for reading or
1136 writing such files are always linked, never independent. Append-type
1137 channels are also always linked. For these channels, follow the rules
1138 for linked channels; see @ref{Linked Channels}.
1140 @node Cleaning Streams
1141 @subsection Cleaning Streams
1143 You can use @code{fflush} to clean a stream in most
1146 You can skip the @code{fflush} if you know the stream
1147 is already clean. A stream is clean whenever its buffer is empty. For
1148 example, an unbuffered stream is always clean. An input stream that is
1149 at end-of-file is clean. A line-buffered stream is clean when the last
1150 character output was a newline. However, a just-opened input stream
1151 might not be clean, as its input buffer might not be empty.
1153 There is one case in which cleaning a stream is impossible on most
1154 systems. This is when the stream is doing input from a file that is not
1155 random-access. Such streams typically read ahead, and when the file is
1156 not random access, there is no way to give back the excess data already
1157 read. When an input stream reads from a random-access file,
1158 @code{fflush} does clean the stream, but leaves the file pointer at an
1159 unpredictable place; you must set the file pointer before doing any
1162 Closing an output-only stream also does @code{fflush}, so this is a
1163 valid way of cleaning an output stream.
1165 You need not clean a stream before using its descriptor for control
1166 operations such as setting terminal modes; these operations don't affect
1167 the file position and are not affected by it. You can use any
1168 descriptor for these operations, and all channels are affected
1169 simultaneously. However, text already ``output'' to a stream but still
1170 buffered by the stream will be subject to the new terminal modes when
1171 subsequently flushed. To make sure ``past'' output is covered by the
1172 terminal settings that were in effect at the time, flush the output
1173 streams for that terminal before setting the modes. @xref{Terminal
1176 @node Scatter-Gather
1177 @section Fast Scatter-Gather I/O
1178 @cindex scatter-gather
1180 Some applications may need to read or write data to multiple buffers,
1181 which are separated in memory. Although this can be done easily enough
1182 with multiple calls to @code{read} and @code{write}, it is inefficient
1183 because there is overhead associated with each kernel call.
1185 Instead, many platforms provide special high-speed primitives to perform
1186 these @dfn{scatter-gather} operations in a single kernel call. @Theglibc{}
1187 will provide an emulation on any system that lacks these
1188 primitives, so they are not a portability threat. They are defined in
1191 These functions are controlled with arrays of @code{iovec} structures,
1192 which describe the location and size of each buffer.
1194 @deftp {Data Type} {struct iovec}
1195 @standards{BSD, sys/uio.h}
1197 The @code{iovec} structure describes a buffer. It contains two fields:
1201 @item void *iov_base
1202 Contains the address of a buffer.
1204 @item size_t iov_len
1205 Contains the length of the buffer.
1210 @deftypefun ssize_t readv (int @var{filedes}, const struct iovec *@var{vector}, int @var{count})
1211 @standards{BSD, sys/uio.h}
1212 @safety{@prelim{}@mtsafe{}@asunsafe{@ascuheap{}}@acunsafe{@acsmem{}}}
1213 @c The fallback sysdeps/posix implementation, used even on GNU/Linux
1214 @c with old kernels that lack a full readv/writev implementation, may
1215 @c malloc the buffer into which data is read, if the total read size is
1216 @c too large for alloca.
1218 The @code{readv} function reads data from @var{filedes} and scatters it
1219 into the buffers described in @var{vector}, which is taken to be
1220 @var{count} structures long. As each buffer is filled, data is sent to the
1223 Note that @code{readv} is not guaranteed to fill all the buffers.
1224 It may stop at any point, for the same reasons @code{read} would.
1226 The return value is a count of bytes (@emph{not} buffers) read, @math{0}
1227 indicating end-of-file, or @math{-1} indicating an error. The possible
1228 errors are the same as in @code{read}.
1232 @deftypefun ssize_t writev (int @var{filedes}, const struct iovec *@var{vector}, int @var{count})
1233 @standards{BSD, sys/uio.h}
1234 @safety{@prelim{}@mtsafe{}@asunsafe{@ascuheap{}}@acunsafe{@acsmem{}}}
1235 @c The fallback sysdeps/posix implementation, used even on GNU/Linux
1236 @c with old kernels that lack a full readv/writev implementation, may
1237 @c malloc the buffer from which data is written, if the total write size
1238 @c is too large for alloca.
1240 The @code{writev} function gathers data from the buffers described in
1241 @var{vector}, which is taken to be @var{count} structures long, and writes
1242 them to @code{filedes}. As each buffer is written, it moves on to the
1245 Like @code{readv}, @code{writev} may stop midstream under the same
1246 conditions @code{write} would.
1248 The return value is a count of bytes written, or @math{-1} indicating an
1249 error. The possible errors are the same as in @code{write}.
1253 @deftypefun ssize_t preadv (int @var{fd}, const struct iovec *@var{iov}, int @var{iovcnt}, off_t @var{offset})
1254 @standards{BSD, sys/uio.h}
1255 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1256 @c This is a syscall for Linux 3.2 for all architectures but microblaze
1257 @c (which was added on 3.15). The sysdeps/posix fallback emulation
1258 @c is also MT-Safe since it calls pread, and it is now a syscall on all
1261 This function is similar to the @code{readv} function, with the difference
1262 it adds an extra @var{offset} parameter of type @code{off_t} similar to
1263 @code{pread}. The data is read from the file starting at position
1264 @var{offset}. The position of the file descriptor itself is not affected
1265 by the operation. The value is the same as before the call.
1267 When the source file is compiled with @code{_FILE_OFFSET_BITS == 64} the
1268 @code{preadv} function is in fact @code{preadv64} and the type
1269 @code{off_t} has 64 bits, which makes it possible to handle files up to
1270 @twoexp{63} bytes in length.
1272 The return value is a count of bytes (@emph{not} buffers) read, @math{0}
1273 indicating end-of-file, or @math{-1} indicating an error. The possible
1274 errors are the same as in @code{readv} and @code{pread}.
1277 @deftypefun ssize_t preadv64 (int @var{fd}, const struct iovec *@var{iov}, int @var{iovcnt}, off64_t @var{offset})
1278 @standards{BSD, unistd.h}
1279 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1280 @c This is a syscall for Linux 3.2 for all architectures but microblaze
1281 @c (which was added on 3.15). The sysdeps/posix fallback emulation
1282 @c is also MT-Safe since it calls pread64, and it is now a syscall on all
1285 This function is similar to the @code{preadv} function with the difference
1286 is that the @var{offset} parameter is of type @code{off64_t} instead of
1287 @code{off_t}. It makes it possible on 32 bit machines to address
1288 files larger than @twoexp{31} bytes and up to @twoexp{63} bytes. The
1289 file descriptor @code{filedes} must be opened using @code{open64} since
1290 otherwise the large offsets possible with @code{off64_t} will lead to
1291 errors with a descriptor in small file mode.
1293 When the source file is compiled using @code{_FILE_OFFSET_BITS == 64} on a
1294 32 bit machine this function is actually available under the name
1295 @code{preadv} and so transparently replaces the 32 bit interface.
1298 @deftypefun ssize_t pwritev (int @var{fd}, const struct iovec *@var{iov}, int @var{iovcnt}, off_t @var{offset})
1299 @standards{BSD, sys/uio.h}
1300 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1301 @c This is a syscall for Linux 3.2 for all architectures but microblaze
1302 @c (which was added on 3.15). The sysdeps/posix fallback emulation
1303 @c is also MT-Safe since it calls pwrite, and it is now a syscall on all
1306 This function is similar to the @code{writev} function, with the difference
1307 it adds an extra @var{offset} parameter of type @code{off_t} similar to
1308 @code{pwrite}. The data is written to the file starting at position
1309 @var{offset}. The position of the file descriptor itself is not affected
1310 by the operation. The value is the same as before the call.
1312 However, on Linux, if a file is opened with @code{O_APPEND}, @code{pwrite}
1313 appends data to the end of the file, regardless of the value of
1316 When the source file is compiled with @code{_FILE_OFFSET_BITS == 64} the
1317 @code{pwritev} function is in fact @code{pwritev64} and the type
1318 @code{off_t} has 64 bits, which makes it possible to handle files up to
1319 @twoexp{63} bytes in length.
1321 The return value is a count of bytes (@emph{not} buffers) written, @math{0}
1322 indicating end-of-file, or @math{-1} indicating an error. The possible
1323 errors are the same as in @code{writev} and @code{pwrite}.
1326 @deftypefun ssize_t pwritev64 (int @var{fd}, const struct iovec *@var{iov}, int @var{iovcnt}, off64_t @var{offset})
1327 @standards{BSD, unistd.h}
1328 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1329 @c This is a syscall for Linux 3.2 for all architectures but microblaze
1330 @c (which was added on 3.15). The sysdeps/posix fallback emulation
1331 @c is also MT-Safe since it calls pwrite64, and it is now a syscall on all
1334 This function is similar to the @code{pwritev} function with the difference
1335 is that the @var{offset} parameter is of type @code{off64_t} instead of
1336 @code{off_t}. It makes it possible on 32 bit machines to address
1337 files larger than @twoexp{31} bytes and up to @twoexp{63} bytes. The
1338 file descriptor @code{filedes} must be opened using @code{open64} since
1339 otherwise the large offsets possible with @code{off64_t} will lead to
1340 errors with a descriptor in small file mode.
1342 When the source file is compiled using @code{_FILE_OFFSET_BITS == 64} on a
1343 32 bit machine this function is actually available under the name
1344 @code{pwritev} and so transparently replaces the 32 bit interface.
1347 @deftypefun ssize_t preadv2 (int @var{fd}, const struct iovec *@var{iov}, int @var{iovcnt}, off_t @var{offset}, int @var{flags})
1348 @standards{GNU, sys/uio.h}
1349 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1350 @c This is a syscall for Linux v4.6. The sysdeps/posix fallback emulation
1351 @c is also MT-Safe since it calls preadv.
1353 This function is similar to the @code{preadv} function, with the
1354 difference it adds an extra @var{flags} parameter of type @code{int}.
1355 Additionally, if @var{offset} is @math{-1}, the current file position
1356 is used and updated (like the @code{readv} function).
1358 The supported @var{flags} are dependent of the underlying system. For
1363 High priority request. This adds a flag that tells the file system that
1364 this is a high priority request for which it is worth to poll the hardware.
1365 The flag is purely advisory and can be ignored if not supported. The
1366 @var{fd} must be opened using @code{O_DIRECT}.
1369 Per-IO synchronization as if the file was opened with @code{O_DSYNC} flag.
1372 Per-IO synchronization as if the file was opened with @code{O_SYNC} flag.
1375 Use nonblocking mode for this operation; that is, this call to @code{preadv2}
1376 will fail and set @code{errno} to @code{EAGAIN} if the operation would block.
1379 Per-IO synchronization as if the file was opened with @code{O_APPEND} flag.
1382 This flag allows an offset to be honored, even if the file was opened with
1383 @code{O_APPEND} flag.
1386 When the source file is compiled with @code{_FILE_OFFSET_BITS == 64} the
1387 @code{preadv2} function is in fact @code{preadv64v2} and the type
1388 @code{off_t} has 64 bits, which makes it possible to handle files up to
1389 @twoexp{63} bytes in length.
1391 The return value is a count of bytes (@emph{not} buffers) read, @math{0}
1392 indicating end-of-file, or @math{-1} indicating an error. The possible
1393 errors are the same as in @code{preadv} with the addition of:
1399 @c The default sysdeps/posix code will return it for any flags value
1400 @c different than 0.
1401 An unsupported @var{flags} was used.
1407 @deftypefun ssize_t preadv64v2 (int @var{fd}, const struct iovec *@var{iov}, int @var{iovcnt}, off64_t @var{offset}, int @var{flags})
1408 @standards{GNU, unistd.h}
1409 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1410 @c This is a syscall for Linux v4.6. The sysdeps/posix fallback emulation
1411 @c is also MT-Safe since it calls preadv.
1413 This function is similar to the @code{preadv2} function with the difference
1414 is that the @var{offset} parameter is of type @code{off64_t} instead of
1415 @code{off_t}. It makes it possible on 32 bit machines to address
1416 files larger than @twoexp{31} bytes and up to @twoexp{63} bytes. The
1417 file descriptor @code{filedes} must be opened using @code{open64} since
1418 otherwise the large offsets possible with @code{off64_t} will lead to
1419 errors with a descriptor in small file mode.
1421 When the source file is compiled using @code{_FILE_OFFSET_BITS == 64} on a
1422 32 bit machine this function is actually available under the name
1423 @code{preadv2} and so transparently replaces the 32 bit interface.
1427 @deftypefun ssize_t pwritev2 (int @var{fd}, const struct iovec *@var{iov}, int @var{iovcnt}, off_t @var{offset}, int @var{flags})
1428 @standards{GNU, sys/uio.h}
1429 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1430 @c This is a syscall for Linux v4.6. The sysdeps/posix fallback emulation
1431 @c is also MT-Safe since it calls pwritev.
1433 This function is similar to the @code{pwritev} function, with the
1434 difference it adds an extra @var{flags} parameter of type @code{int}.
1435 Additionally, if @var{offset} is @math{-1}, the current file position
1436 should is used and updated (like the @code{writev} function).
1438 The supported @var{flags} are dependent of the underlying system. For
1439 Linux, the supported flags are the same as those for @code{preadv2}.
1441 When the source file is compiled with @code{_FILE_OFFSET_BITS == 64} the
1442 @code{pwritev2} function is in fact @code{pwritev64v2} and the type
1443 @code{off_t} has 64 bits, which makes it possible to handle files up to
1444 @twoexp{63} bytes in length.
1446 The return value is a count of bytes (@emph{not} buffers) write, @math{0}
1447 indicating end-of-file, or @math{-1} indicating an error. The possible
1448 errors are the same as in @code{preadv2}.
1451 @deftypefun ssize_t pwritev64v2 (int @var{fd}, const struct iovec *@var{iov}, int @var{iovcnt}, off64_t @var{offset}, int @var{flags})
1452 @standards{GNU, unistd.h}
1453 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1454 @c This is a syscall for Linux v4.6. The sysdeps/posix fallback emulation
1455 @c is also MT-Safe since it calls pwritev.
1457 This function is similar to the @code{pwritev2} function with the difference
1458 is that the @var{offset} parameter is of type @code{off64_t} instead of
1459 @code{off_t}. It makes it possible on 32 bit machines to address
1460 files larger than @twoexp{31} bytes and up to @twoexp{63} bytes. The
1461 file descriptor @code{filedes} must be opened using @code{open64} since
1462 otherwise the large offsets possible with @code{off64_t} will lead to
1463 errors with a descriptor in small file mode.
1465 When the source file is compiled using @code{_FILE_OFFSET_BITS == 64} on a
1466 32 bit machine this function is actually available under the name
1467 @code{pwritev2} and so transparently replaces the 32 bit interface.
1470 @node Copying File Data
1471 @section Copying data between two files
1472 @cindex copying files
1475 A special function is provided to copy data between two files on the
1476 same file system. The system can optimize such copy operations. This
1477 is particularly important on network file systems, where the data would
1478 otherwise have to be transferred twice over the network.
1480 Note that this function only copies file data, but not metadata such as
1481 file permissions or extended attributes.
1483 @deftypefun ssize_t copy_file_range (int @var{inputfd}, off64_t *@var{inputpos}, int @var{outputfd}, off64_t *@var{outputpos}, ssize_t @var{length}, unsigned int @var{flags})
1484 @standards{GNU, unistd.h}
1485 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1487 This function copies up to @var{length} bytes from the file descriptor
1488 @var{inputfd} to the file descriptor @var{outputfd}.
1490 The function can operate on both the current file position (like
1491 @code{read} and @code{write}) and an explicit offset (like @code{pread}
1492 and @code{pwrite}). If the @var{inputpos} pointer is null, the file
1493 position of @var{inputfd} is used as the starting point of the copy
1494 operation, and the file position is advanced during it. If
1495 @var{inputpos} is not null, then @code{*@var{inputpos}} is used as the
1496 starting point of the copy operation, and @code{*@var{inputpos}} is
1497 incremented by the number of copied bytes, but the file position remains
1498 unchanged. Similar rules apply to @var{outputfd} and @var{outputpos}
1499 for the output file position.
1501 The @var{flags} argument is currently reserved and must be zero.
1503 The @code{copy_file_range} function returns the number of bytes copied.
1504 This can be less than the specified @var{length} in case the input file
1505 contains fewer remaining bytes than @var{length}, or if a read or write
1506 failure occurs. The return value is zero if the end of the input file
1507 is encountered immediately.
1509 If no bytes can be copied, to report an error, @code{copy_file_range}
1510 returns the value @math{-1} and sets @code{errno}. The table below
1511 lists some of the error conditions for this function.
1515 The kernel does not implement the required functionality.
1518 At least one of the descriptors @var{inputfd} or @var{outputfd} refers
1522 At least one of the descriptors @var{inputfd} or @var{outputfd} refers
1523 to a non-regular, non-directory file (such as a socket or a FIFO).
1525 The input or output positions before are after the copy operations are
1526 outside of an implementation-defined limit.
1528 The @var{flags} argument is not zero.
1531 The new file size would exceed the process file size limit.
1532 @xref{Limits on Resources}.
1534 The input or output positions before are after the copy operations are
1535 outside of an implementation-defined limit. This can happen if the file
1536 was not opened with large file support (LFS) on 32-bit machines, and the
1537 copy operation would create a file which is larger than what
1538 @code{off_t} could represent.
1541 The argument @var{inputfd} is not a valid file descriptor open for
1544 The argument @var{outputfd} is not a valid file descriptor open for
1545 writing, or @var{outputfd} has been opened with @code{O_APPEND}.
1548 In addition, @code{copy_file_range} can fail with the error codes
1549 which are used by @code{read}, @code{pread}, @code{write}, and
1552 The @code{copy_file_range} function is a cancellation point. In case of
1553 cancellation, the input location (the file position or the value at
1554 @code{*@var{inputpos}}) is indeterminate.
1557 @node Memory-mapped I/O
1558 @section Memory-mapped I/O
1560 On modern operating systems, it is possible to @dfn{mmap} (pronounced
1561 ``em-map'') a file to a region of memory. When this is done, the file can
1562 be accessed just like an array in the program.
1564 This is more efficient than @code{read} or @code{write}, as only the regions
1565 of the file that a program actually accesses are loaded. Accesses to
1566 not-yet-loaded parts of the mmapped region are handled in the same way as
1569 Since mmapped pages can be stored back to their file when physical
1570 memory is low, it is possible to mmap files orders of magnitude larger
1571 than both the physical memory @emph{and} swap space. The only limit is
1572 address space. The theoretical limit is 4GB on a 32-bit machine -
1573 however, the actual limit will be smaller since some areas will be
1574 reserved for other purposes. If the LFS interface is used the file size
1575 on 32-bit systems is not limited to 2GB (offsets are signed which
1576 reduces the addressable area of 4GB by half); the full 64-bit are
1579 Memory mapping only works on entire pages of memory. Thus, addresses
1580 for mapping must be page-aligned, and length values will be rounded up.
1581 To determine the default size of a page the machine uses one should use:
1583 @vindex _SC_PAGESIZE
1585 size_t page_size = (size_t) sysconf (_SC_PAGESIZE);
1588 On some systems, mappings can use larger page sizes
1589 for certain files, and applications can request larger page sizes for
1590 anonymous mappings as well (see the @code{MAP_HUGETLB} flag below).
1592 The following functions are declared in @file{sys/mman.h}:
1594 @deftypefun {void *} mmap (void *@var{address}, size_t @var{length}, int @var{protect}, int @var{flags}, int @var{filedes}, off_t @var{offset})
1595 @standards{POSIX, sys/mman.h}
1596 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1598 The @code{mmap} function creates a new mapping, connected to bytes
1599 (@var{offset}) to (@var{offset} + @var{length} - 1) in the file open on
1600 @var{filedes}. A new reference for the file specified by @var{filedes}
1601 is created, which is not removed by closing the file.
1603 @var{address} gives a preferred starting address for the mapping.
1604 @code{NULL} expresses no preference. Any previous mapping at that
1605 address is automatically removed. The address you give may still be
1606 changed, unless you use the @code{MAP_FIXED} flag.
1608 @var{protect} contains flags that control what kind of access is
1609 permitted. They include @code{PROT_READ}, @code{PROT_WRITE}, and
1610 @code{PROT_EXEC}. The special flag @code{PROT_NONE} reserves a region
1611 of address space for future use. The @code{mprotect} function can be
1612 used to change the protection flags. @xref{Memory Protection}.
1614 The @var{flags} parameter contains flags that control the nature of
1615 the map. One of @code{MAP_SHARED}, @code{MAP_SHARED_VALIDATE}, or
1616 @code{MAP_PRIVATE} must be specified. Additional flags may be bitwise
1617 OR'd to further define the mapping.
1619 Note that, aside from @code{MAP_PRIVATE} and @code{MAP_SHARED}, not
1620 all flags are supported on all versions of all operating systems.
1621 Consult the kernel-specific documentation for details. The flags
1626 This specifies that writes to the region should never be written back
1627 to the attached file. Instead, a copy is made for the process, and the
1628 region will be swapped normally if memory runs low. No other process will
1631 Since private mappings effectively revert to ordinary memory
1632 when written to, you must have enough virtual memory for a copy of
1633 the entire mmapped region if you use this mode with @code{PROT_WRITE}.
1636 This specifies that writes to the region will be written back to the
1637 file. Changes made will be shared immediately with other processes
1638 mmaping the same file.
1640 Note that actual writing may take place at any time. You need to use
1641 @code{msync}, described below, if it is important that other processes
1642 using conventional I/O get a consistent view of the file.
1644 @item MAP_SHARED_VALIDATE
1645 Similar to @code{MAP_SHARED} except that additional flags will be
1646 validated by the kernel, and the call will fail if an unrecognized
1647 flag is provided. With @code{MAP_SHARED} using a flag on a kernel
1648 that doesn't support it causes the flag to be ignored.
1649 @code{MAP_SHARED_VALIDATE} should be used when the behavior of all
1653 This forces the system to use the exact mapping address specified in
1654 @var{address} and fail if it can't. Note that if the new mapping
1655 would overlap an existing mapping, the overlapping portion of the
1656 existing map is unmapped.
1658 @c One of these is official - the other is obviously an obsolete synonym
1662 This flag tells the system to create an anonymous mapping, not connected
1663 to a file. @var{filedes} and @var{offset} are ignored, and the region is
1664 initialized with zeros.
1666 Anonymous maps are used as the basic primitive to extend the heap on some
1667 systems. They are also useful to share data between multiple tasks
1668 without creating a file.
1670 On some systems using private anonymous mmaps is more efficient than using
1671 @code{malloc} for large blocks. This is not an issue with @theglibc{},
1672 as the included @code{malloc} automatically uses @code{mmap} where appropriate.
1675 @standards{Linux, sys/mman.h}
1676 This requests that the system uses an alternative page size which is
1677 larger than the default page size for the mapping. For some workloads,
1678 increasing the page size for large mappings improves performance because
1679 the system needs to handle far fewer pages. For other workloads which
1680 require frequent transfer of pages between storage or different nodes,
1681 the decreased page granularity may cause performance problems due to the
1682 increased page size and larger transfers.
1684 In order to create the mapping, the system needs physically contiguous
1685 memory of the size of the increased page size. As a result,
1686 @code{MAP_HUGETLB} mappings are affected by memory fragmentation, and
1687 their creation can fail even if plenty of memory is available in the
1690 Not all file systems support mappings with an increased page size.
1692 The @code{MAP_HUGETLB} flag is specific to Linux.
1694 @c There is a mechanism to select different hugepage sizes; see
1695 @c include/uapi/asm-generic/hugetlb_encode.h in the kernel sources.
1698 Require addresses that can be accessed with a signed 32 bit pointer,
1699 i.e., within the first 2 GiB. Ignored if MAP_FIXED is specified.
1702 @itemx MAP_EXECUTABLE
1705 Provided for compatibility. Ignored by the Linux kernel.
1707 @item MAP_FIXED_NOREPLACE
1708 Similar to @code{MAP_FIXED} except the call will fail with
1709 @code{EEXIST} if the new mapping would overwrite an existing mapping.
1710 To test for support for this flag, specify MAP_FIXED_NOREPLACE without
1711 MAP_FIXED, and (if the call was successful) check the actual address
1712 returned. If it does not match the address passed, then this flag is
1716 This flag is used to make stacks, and is typically only needed inside
1717 the program loader to set up the main stack for the running process.
1718 The mapping is created according to the other flags, except an
1719 additional page just prior to the mapping is marked as a ``guard
1720 page''. If a write is attempted inside this guard page, that page is
1721 mapped, the mapping is extended, and a new guard page is created.
1722 Thus, the mapping continues to grow towards lower addresses until it
1723 encounters some other mapping.
1725 Note that accessing memory beyond the guard page will not trigger this
1726 feature. In gcc, use @code{-fstack-clash-protection} to ensure the
1727 guard page is always touched.
1730 A hint that requests that mapped pages are locked in memory (i.e. not
1731 paged out). Note that this is a request and not a requirement; use
1732 @code{mlock} if locking is required.
1736 @code{MAP_POPULATE} is a hint that requests that the kernel read-ahead
1737 a file-backed mapping, causing pages to be mapped before they're
1738 needed. @code{MAP_NONBLOCK} is a hint that requests that the kernel
1739 @emph{not} attempt such except for pages are already in memory. Note
1740 that neither of these hints affects future paging activity, use
1741 @code{mlock} if such needs to be controlled.
1744 Asks the kernel to not reserve physical backing (i.e. space in a swap
1745 device) for a mapping. This would be useful for, for example, a very
1746 large but sparsely used mapping which need not be limited in total
1747 length by available RAM, but with very few mapped pages. Note that
1748 writes to such a mapping may cause a @code{SIGSEGV} if the system is
1749 unable to map a page due to lack of resources.
1751 On Linux, this flag's behavior may be overwridden by
1752 @file{/proc/sys/vm/overcommit_memory} as documented in the proc(5) man
1756 Ensures that the resulting mapping is suitable for use as a program
1757 stack. For example, the use of huge pages might be precluded.
1760 This is a special flag for DAX devices, which tells the kernel to
1761 write dirty metadata out whenever dirty data is written out. Unlike
1762 most other flags, this one will fail unless @code{MAP_SHARED_VALIDATE}
1767 @code{mmap} returns the address of the new mapping, or
1768 @code{MAP_FAILED} for an error.
1770 Possible errors include:
1776 @var{filedes} was not open for the type of access specified in @var{protect}.
1780 The system has temporarily run out of resources.
1784 The @var{fd} passed is invalid, and a valid file descriptor is
1785 required (i.e. MAP_ANONYMOUS was not specified).
1789 @code{MAP_FIXED_NOREPLACE} was specified and an existing mapping was
1790 found overlapping the requested address range.
1794 Either @var{address} was unusable (because it is not a multiple of the
1795 applicable page size), or inconsistent @var{flags} were given.
1797 If @code{MAP_HUGETLB} was specified, the file or system does not support
1802 This file is of a type that doesn't support mapping, the process has
1803 exceeded its data space limit, or the map request would exceed the
1804 process's virtual address space.
1808 There is not enough memory for the operation, the process is out of
1809 address space, or there are too many mappings. On Linux, the maximum
1810 number of mappings can be controlled via
1811 @file{/proc/sys/vm/max_map_count} or, if your OS supports it, via
1812 the @code{vm.max_map_count} @code{sysctl} setting.
1816 The file is on a filesystem that doesn't support mapping.
1820 @code{PROT_EXEC} was requested but the file is on a filesystem that
1821 was mounted with execution denied, a file seal prevented the mapping,
1822 or the caller set MAP_HUDETLB but does not have the required
1827 Either the offset into the file plus the length of the mapping causes
1828 internal page counts to overflow, or the offset requested exceeds the
1831 @c On Linux, EAGAIN will appear if the file has a conflicting mandatory lock.
1832 @c However mandatory locks are not discussed in this manual.
1834 @c Similarly, ETXTBSY will occur if the MAP_DENYWRITE flag (not documented
1835 @c here) is used and the file is already open for writing.
1841 @deftypefun {void *} mmap64 (void *@var{address}, size_t @var{length}, int @var{protect}, int @var{flags}, int @var{filedes}, off64_t @var{offset})
1842 @standards{LFS, sys/mman.h}
1843 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1844 @c The page_shift auto detection when MMAP2_PAGE_SHIFT is -1 (it never
1845 @c is) would be thread-unsafe.
1846 The @code{mmap64} function is equivalent to the @code{mmap} function but
1847 the @var{offset} parameter is of type @code{off64_t}. On 32-bit systems
1848 this allows the file associated with the @var{filedes} descriptor to be
1849 larger than 2GB. @var{filedes} must be a descriptor returned from a
1850 call to @code{open64} or @code{fopen64} and @code{freopen64} where the
1851 descriptor is retrieved with @code{fileno}.
1853 When the sources are translated with @code{_FILE_OFFSET_BITS == 64} this
1854 function is actually available under the name @code{mmap}. I.e., the
1855 new, extended API using 64 bit file sizes and offsets transparently
1856 replaces the old API.
1859 @deftypefun int munmap (void *@var{addr}, size_t @var{length})
1860 @standards{POSIX, sys/mman.h}
1861 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1863 @code{munmap} removes any memory maps from (@var{addr}) to (@var{addr} +
1864 @var{length}). @var{length} should be the length of the mapping.
1866 It is safe to unmap multiple mappings in one command, or include unmapped
1867 space in the range. It is also possible to unmap only part of an existing
1868 mapping. However, only entire pages can be removed. If @var{length} is not
1869 an even number of pages, it will be rounded up.
1871 It returns @math{0} for success and @math{-1} for an error.
1873 One error is possible:
1878 The memory range given was outside the user mmap range or wasn't page
1885 @deftypefun int msync (void *@var{address}, size_t @var{length}, int @var{flags})
1886 @standards{POSIX, sys/mman.h}
1887 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1889 When using shared mappings, the kernel can write the file at any time
1890 before the mapping is removed. To be certain data has actually been
1891 written to the file and will be accessible to non-memory-mapped I/O, it
1892 is necessary to use this function.
1894 It operates on the region @var{address} to (@var{address} + @var{length}).
1895 It may be used on part of a mapping or multiple mappings, however the
1896 region given should not contain any unmapped space.
1898 @var{flags} can contain some options:
1904 This flag makes sure the data is actually written @emph{to disk}.
1905 Normally @code{msync} only makes sure that accesses to a file with
1906 conventional I/O reflect the recent changes.
1910 This tells @code{msync} to begin the synchronization, but not to wait for
1913 @c Linux also has MS_INVALIDATE, which I don't understand.
1917 @code{msync} returns @math{0} for success and @math{-1} for
1918 error. Errors include:
1923 An invalid region was given, or the @var{flags} were invalid.
1926 There is no existing mapping in at least part of the given region.
1932 @deftypefun {void *} mremap (void *@var{address}, size_t @var{length}, size_t @var{new_length}, int @var{flag}, ... /* void *@var{new_address} */)
1933 @standards{GNU, sys/mman.h}
1934 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1936 This function can be used to change the size of an existing memory
1937 area. @var{address} and @var{length} must cover a region entirely mapped
1938 in the same @code{mmap} statement. A new mapping with the same
1939 characteristics will be returned with the length @var{new_length}.
1945 @item MREMAP_MAYMOVE
1946 If it is given in @var{flags}, the system may remove the existing mapping
1947 and create a new one of the desired length in another location.
1950 If it is given in @var{flags}, @code{mremap} accepts a fifth argument,
1951 @code{void *new_address}, which specifies a page-aligned address to
1952 which the mapping must be moved. Any previous mapping at the address
1953 range specified by @var{new_address} and @var{new_size} is unmapped.
1955 @code{MREMAP_FIXED} must be used together with @code{MREMAP_MAYMOVE}.
1957 @item MREMAP_DONTUNMAP
1958 If it is given in @var{flags}, @code{mremap} accepts a fifth argument,
1959 @code{void *new_address}, which specifies a page-aligned address. Any
1960 previous mapping at the address range specified by @var{new_address} and
1961 @var{new_size} is unmapped. If @var{new_address} is @code{NULL}, the
1962 kernel chooses the page-aligned address at which to create the mapping.
1963 Otherwise, the kernel takes it as a hint about where to place the mapping.
1964 The mapping at the address range specified by @var{old_address} and
1965 @var{old_size} isn't unmapped.
1967 @code{MREMAP_DONTUNMAP} must be used together with @code{MREMAP_MAYMOVE}.
1968 @var{old_size} must be the same as @var{new_size}. This flag bit is
1973 The address of the resulting mapping is returned, or @code{MAP_FAILED}.
1974 Possible error codes include:
1979 There is no existing mapping in at least part of the original region, or
1980 the region covers two or more distinct mappings.
1983 Any arguments are inappropriate, including unknown @var{flags} values.
1986 The region has pages locked, and if extended it would exceed the
1987 process's resource limit for locked pages. @xref{Limits on Resources}.
1990 The region is private writable, and insufficient virtual memory is
1991 available to extend it. Also, this error will occur if
1992 @code{MREMAP_MAYMOVE} is not given and the extension would collide with
1993 another mapped region.
1998 This function is only available on a few systems. Except for performing
1999 optional optimizations one should not rely on this function.
2001 Not all file descriptors may be mapped. Sockets, pipes, and most devices
2002 only allow sequential access and do not fit into the mapping abstraction.
2003 In addition, some regular files may not be mmapable, and older kernels may
2004 not support mapping at all. Thus, programs using @code{mmap} should
2005 have a fallback method to use should it fail. @xref{Mmap,,,standards,GNU
2008 @deftypefun int madvise (void *@var{addr}, size_t @var{length}, int @var{advice})
2009 @standards{POSIX, sys/mman.h}
2010 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
2012 This function can be used to provide the system with @var{advice} about
2013 the intended usage patterns of the memory region starting at @var{addr}
2014 and extending @var{length} bytes.
2016 The valid BSD values for @var{advice} are:
2021 The region should receive no further special treatment.
2024 The region will be accessed via random page references. The kernel
2025 should page-in the minimal number of pages for each page fault.
2027 @item MADV_SEQUENTIAL
2028 The region will be accessed via sequential page references. This
2029 may cause the kernel to aggressively read-ahead, expecting further
2030 sequential references after any page fault within this region.
2033 The region will be needed. The pages within this region may
2034 be pre-faulted in by the kernel.
2037 The region is no longer needed. The kernel may free these pages,
2038 causing any changes to the pages to be lost, as well as swapped
2039 out pages to be discarded.
2042 @standards{Linux, sys/mman.h}
2043 Indicate that it is beneficial to increase the page size for this
2044 mapping. This can improve performance for larger mappings because the
2045 system needs to handle far fewer pages. However, if parts of the
2046 mapping are frequently transferred between storage or different nodes,
2047 performance may suffer because individual transfers can become
2048 substantially larger due to the increased page size.
2050 This flag is specific to Linux.
2052 @item MADV_NOHUGEPAGE
2053 Undo the effect of a previous @code{MADV_HUGEPAGE} advice. This flag
2054 is specific to Linux.
2058 The POSIX names are slightly different, but with the same meanings:
2062 @item POSIX_MADV_NORMAL
2063 This corresponds with BSD's @code{MADV_NORMAL}.
2065 @item POSIX_MADV_RANDOM
2066 This corresponds with BSD's @code{MADV_RANDOM}.
2068 @item POSIX_MADV_SEQUENTIAL
2069 This corresponds with BSD's @code{MADV_SEQUENTIAL}.
2071 @item POSIX_MADV_WILLNEED
2072 This corresponds with BSD's @code{MADV_WILLNEED}.
2074 @item POSIX_MADV_DONTNEED
2075 This corresponds with BSD's @code{MADV_DONTNEED}.
2079 @code{madvise} returns @math{0} for success and @math{-1} for
2080 error. Errors include:
2084 An invalid region was given, or the @var{advice} was invalid.
2087 There is no existing mapping in at least part of the given region.
2092 @deftypefn Function int shm_open (const char *@var{name}, int @var{oflag}, mode_t @var{mode})
2093 @standards{POSIX, sys/mman.h}
2094 @safety{@prelim{}@mtsafe{@mtslocale{}}@asunsafe{@asuinit{} @ascuheap{} @asulock{}}@acunsafe{@aculock{} @acsmem{} @acsfd{}}}
2095 @c shm_open @mtslocale @asuinit @ascuheap @asulock @aculock @acsmem @acsfd
2096 @c libc_once(where_is_shmfs) @mtslocale @asuinit @ascuheap @asulock @aculock @acsmem @acsfd
2097 @c where_is_shmfs @mtslocale @ascuheap @asulock @aculock @acsmem @acsfd
2099 @c setmntent dup @ascuheap @asulock @acsmem @acsfd @aculock
2100 @c getmntent_r dup @mtslocale @ascuheap @aculock @acsmem [no @asucorrupt @acucorrupt; exclusive stream]
2103 @c malloc dup @ascuheap @acsmem
2105 @c endmntent dup @ascuheap @asulock @aculock @acsmem @acsfd
2113 This function returns a file descriptor that can be used to allocate shared
2114 memory via mmap. Unrelated processes can use same @var{name} to create or
2115 open existing shared memory objects.
2117 A @var{name} argument specifies the shared memory object to be opened.
2118 In @theglibc{} it must be a string smaller than @code{NAME_MAX} bytes starting
2119 with an optional slash but containing no other slashes.
2121 The semantics of @var{oflag} and @var{mode} arguments is same as in @code{open}.
2123 @code{shm_open} returns the file descriptor on success or @math{-1} on error.
2124 On failure @code{errno} is set.
2127 @deftypefn Function int shm_unlink (const char *@var{name})
2128 @safety{@prelim{}@mtsafe{@mtslocale{}}@asunsafe{@asuinit{} @ascuheap{} @asulock{}}@acunsafe{@aculock{} @acsmem{} @acsfd{}}}
2129 @c shm_unlink @mtslocale @asuinit @ascuheap @asulock @aculock @acsmem @acsfd
2130 @c libc_once(where_is_shmfs) dup @mtslocale @asuinit @ascuheap @asulock @aculock @acsmem @acsfd
2136 This function is the inverse of @code{shm_open} and removes the object with
2137 the given @var{name} previously created by @code{shm_open}.
2139 @code{shm_unlink} returns @math{0} on success or @math{-1} on error.
2140 On failure @code{errno} is set.
2143 @deftypefun int memfd_create (const char *@var{name}, unsigned int @var{flags})
2144 @standards{Linux, sys/mman.h}
2145 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{@acsfd{}}}
2146 The @code{memfd_create} function returns a file descriptor which can be
2147 used to create memory mappings using the @code{mmap} function. It is
2148 similar to the @code{shm_open} function in the sense that these mappings
2149 are not backed by actual files. However, the descriptor returned by
2150 @code{memfd_create} does not correspond to a named object; the
2151 @var{name} argument is used for debugging purposes only (e.g., will
2152 appear in @file{/proc}), and separate invocations of @code{memfd_create}
2153 with the same @var{name} will not return descriptors for the same region
2154 of memory. The descriptor can also be used to create alias mappings
2155 within the same process.
2157 The descriptor initially refers to a zero-length file. Before mappings
2158 can be created which are backed by memory, the file size needs to be
2159 increased with the @code{ftruncate} function. @xref{File Size}.
2161 The @var{flags} argument can be a combination of the following flags:
2165 @standards{Linux, sys/mman.h}
2166 The descriptor is created with the @code{O_CLOEXEC} flag.
2168 @item MFD_ALLOW_SEALING
2169 @standards{Linux, sys/mman.h}
2170 The descriptor supports the addition of seals using the @code{fcntl}
2174 @standards{Linux, sys/mman.h}
2175 This requests that mappings created using the returned file descriptor
2176 use a larger page size. See @code{MAP_HUGETLB} above for details.
2178 This flag is incompatible with @code{MFD_ALLOW_SEALING}.
2181 @code{memfd_create} returns a file descriptor on success, and @math{-1}
2184 The following @code{errno} error conditions are defined for this
2189 An invalid combination is specified in @var{flags}, or @var{name} is
2193 The @var{name} argument does not point to a string.
2196 The operation would exceed the file descriptor limit for this process.
2199 The operation would exceed the system-wide file descriptor limit.
2202 There is not enough memory for the operation.
2206 @node Waiting for I/O
2207 @section Waiting for Input or Output
2208 @cindex waiting for input or output
2209 @cindex multiplexing input
2210 @cindex input from multiple files
2212 Sometimes a program needs to accept input on multiple input channels
2213 whenever input arrives. For example, some workstations may have devices
2214 such as a digitizing tablet, function button box, or dial box that are
2215 connected via normal asynchronous serial interfaces; good user interface
2216 style requires responding immediately to input on any device. Another
2217 example is a program that acts as a server to several other processes
2218 via pipes or sockets.
2220 You cannot normally use @code{read} for this purpose, because this
2221 blocks the program until input is available on one particular file
2222 descriptor; input on other channels won't wake it up. You could set
2223 nonblocking mode and poll each file descriptor in turn, but this is very
2226 A better solution is to use the @code{select} function. This blocks the
2227 program until input or output is ready on a specified set of file
2228 descriptors, or until a timer expires, whichever comes first. This
2229 facility is declared in the header file @file{sys/types.h}.
2232 In the case of a server socket (@pxref{Listening}), we say that
2233 ``input'' is available when there are pending connections that could be
2234 accepted (@pxref{Accepting Connections}). @code{accept} for server
2235 sockets blocks and interacts with @code{select} just as @code{read} does
2238 @cindex file descriptor sets, for @code{select}
2239 The file descriptor sets for the @code{select} function are specified
2240 as @code{fd_set} objects. Here is the description of the data type
2241 and some macros for manipulating these objects.
2243 @deftp {Data Type} fd_set
2244 @standards{BSD, sys/types.h}
2245 The @code{fd_set} data type represents file descriptor sets for the
2246 @code{select} function. It is actually a bit array.
2249 @deftypevr Macro int FD_SETSIZE
2250 @standards{BSD, sys/types.h}
2251 The value of this macro is the maximum number of file descriptors that a
2252 @code{fd_set} object can hold information about. On systems with a
2253 fixed maximum number, @code{FD_SETSIZE} is at least that number. On
2254 some systems, including GNU, there is no absolute limit on the number of
2255 descriptors open, but this macro still has a constant value which
2256 controls the number of bits in an @code{fd_set}; if you get a file
2257 descriptor with a value as high as @code{FD_SETSIZE}, you cannot put
2258 that descriptor into an @code{fd_set}.
2261 @deftypefn Macro void FD_ZERO (fd_set *@var{set})
2262 @standards{BSD, sys/types.h}
2263 @safety{@prelim{}@mtsafe{@mtsrace{:set}}@assafe{}@acsafe{}}
2264 This macro initializes the file descriptor set @var{set} to be the
2268 @deftypefn Macro void FD_SET (int @var{filedes}, fd_set *@var{set})
2269 @standards{BSD, sys/types.h}
2270 @safety{@prelim{}@mtsafe{@mtsrace{:set}}@assafe{}@acsafe{}}
2271 @c Setting a bit isn't necessarily atomic, so there's a potential race
2272 @c here if set is not used exclusively.
2273 This macro adds @var{filedes} to the file descriptor set @var{set}.
2275 The @var{filedes} parameter must not have side effects since it is
2276 evaluated more than once.
2279 @deftypefn Macro void FD_CLR (int @var{filedes}, fd_set *@var{set})
2280 @standards{BSD, sys/types.h}
2281 @safety{@prelim{}@mtsafe{@mtsrace{:set}}@assafe{}@acsafe{}}
2282 @c Setting a bit isn't necessarily atomic, so there's a potential race
2283 @c here if set is not used exclusively.
2284 This macro removes @var{filedes} from the file descriptor set @var{set}.
2286 The @var{filedes} parameter must not have side effects since it is
2287 evaluated more than once.
2290 @deftypefn Macro int FD_ISSET (int @var{filedes}, const fd_set *@var{set})
2291 @standards{BSD, sys/types.h}
2292 @safety{@prelim{}@mtsafe{@mtsrace{:set}}@assafe{}@acsafe{}}
2293 This macro returns a nonzero value (true) if @var{filedes} is a member
2294 of the file descriptor set @var{set}, and zero (false) otherwise.
2296 The @var{filedes} parameter must not have side effects since it is
2297 evaluated more than once.
2300 Next, here is the description of the @code{select} function itself.
2302 @deftypefun int select (int @var{nfds}, fd_set *@var{read-fds}, fd_set *@var{write-fds}, fd_set *@var{except-fds}, struct timeval *@var{timeout})
2303 @standards{BSD, sys/types.h}
2304 @safety{@prelim{}@mtsafe{@mtsrace{:read-fds} @mtsrace{:write-fds} @mtsrace{:except-fds}}@assafe{}@acsafe{}}
2305 @c The select syscall is preferred, but pselect6 may be used instead,
2306 @c which requires converting timeout to a timespec and back. The
2307 @c conversions are not atomic.
2308 The @code{select} function blocks the calling process until there is
2309 activity on any of the specified sets of file descriptors, or until the
2310 timeout period has expired.
2312 The file descriptors specified by the @var{read-fds} argument are
2313 checked to see if they are ready for reading; the @var{write-fds} file
2314 descriptors are checked to see if they are ready for writing; and the
2315 @var{except-fds} file descriptors are checked for exceptional
2316 conditions. You can pass a null pointer for any of these arguments if
2317 you are not interested in checking for that kind of condition.
2319 A file descriptor is considered ready for reading if a @code{read}
2320 call will not block. This usually includes the read offset being at
2321 the end of the file or there is an error to report. A server socket
2322 is considered ready for reading if there is a pending connection which
2323 can be accepted with @code{accept}; @pxref{Accepting Connections}. A
2324 client socket is ready for writing when its connection is fully
2325 established; @pxref{Connecting}.
2327 ``Exceptional conditions'' does not mean errors---errors are reported
2328 immediately when an erroneous system call is executed, and do not
2329 constitute a state of the descriptor. Rather, they include conditions
2330 such as the presence of an urgent message on a socket. (@xref{Sockets},
2331 for information on urgent messages.)
2333 The @code{select} function checks only the first @var{nfds} file
2334 descriptors. The usual thing is to pass @code{FD_SETSIZE} as the value
2337 The @var{timeout} specifies the maximum time to wait. If you pass a
2338 null pointer for this argument, it means to block indefinitely until
2339 one of the file descriptors is ready. Otherwise, you should provide
2340 the time in @code{struct timeval} format; see @ref{Time Types}.
2341 Specify zero as the time (a @code{struct timeval} containing all
2342 zeros) if you want to find out which descriptors are ready without
2343 waiting if none are ready.
2345 The normal return value from @code{select} is the total number of ready file
2346 descriptors in all of the sets. Each of the argument sets is overwritten
2347 with information about the descriptors that are ready for the corresponding
2348 operation. Thus, to see if a particular descriptor @var{desc} has input,
2349 use @code{FD_ISSET (@var{desc}, @var{read-fds})} after @code{select} returns.
2351 If @code{select} returns because the timeout period expires, it returns
2354 Any signal will cause @code{select} to return immediately. So if your
2355 program uses signals, you can't rely on @code{select} to keep waiting
2356 for the full time specified. If you want to be sure of waiting for a
2357 particular amount of time, you must check for @code{EINTR} and repeat
2358 the @code{select} with a newly calculated timeout based on the current
2359 time. See the example below. See also @ref{Interrupted Primitives}.
2361 If an error occurs, @code{select} returns @code{-1} and does not modify
2362 the argument file descriptor sets. The following @code{errno} error
2363 conditions are defined for this function:
2367 One of the file descriptor sets specified an invalid file descriptor.
2370 The operation was interrupted by a signal. @xref{Interrupted Primitives}.
2373 The @var{timeout} argument is invalid; one of the components is negative
2378 @strong{Portability Note:} The @code{select} function is a BSD Unix
2381 Here is an example showing how you can use @code{select} to establish a
2382 timeout period for reading from a file descriptor. The @code{input_timeout}
2383 function blocks the calling process until input is available on the
2384 file descriptor, or until the timeout period expires.
2387 @include select.c.texi
2390 There is another example showing the use of @code{select} to multiplex
2391 input from multiple sockets in @ref{Server Example}.
2393 For an alternate interface to this functionality, see @code{poll}
2394 (@pxref{Other Low-Level I/O APIs}).
2396 @node Synchronizing I/O
2397 @section Synchronizing I/O operations
2399 @cindex synchronizing
2400 In most modern operating systems, the normal I/O operations are not
2401 executed synchronously. I.e., even if a @code{write} system call
2402 returns, this does not mean the data is actually written to the media,
2405 In situations where synchronization points are necessary, you can use
2406 special functions which ensure that all operations finish before
2409 @deftypefun void sync (void)
2410 @standards{X/Open, unistd.h}
2411 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
2412 A call to this function will not return as long as there is data which
2413 has not been written to the device. All dirty buffers in the kernel will
2414 be written and so an overall consistent system can be achieved (if no
2415 other process in parallel writes data).
2417 A prototype for @code{sync} can be found in @file{unistd.h}.
2420 Programs more often want to ensure that data written to a given file is
2421 committed, rather than all data in the system. For this, @code{sync} is overkill.
2424 @deftypefun int fsync (int @var{fildes})
2425 @standards{POSIX, unistd.h}
2426 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
2427 The @code{fsync} function can be used to make sure all data associated with
2428 the open file @var{fildes} is written to the device associated with the
2429 descriptor. The function call does not return unless all actions have
2432 A prototype for @code{fsync} can be found in @file{unistd.h}.
2434 This function is a cancellation point in multi-threaded programs. This
2435 is a problem if the thread allocates some resources (like memory, file
2436 descriptors, semaphores or whatever) at the time @code{fsync} is
2437 called. If the thread gets canceled these resources stay allocated
2438 until the program ends. To avoid this, calls to @code{fsync} should be
2439 protected using cancellation handlers.
2440 @c ref pthread_cleanup_push / pthread_cleanup_pop
2442 The return value of the function is zero if no error occurred. Otherwise
2443 it is @math{-1} and the global variable @code{errno} is set to the
2447 The descriptor @var{fildes} is not valid.
2450 No synchronization is possible since the system does not implement this.
2454 Sometimes it is not even necessary to write all data associated with a
2455 file descriptor. E.g., in database files which do not change in size it
2456 is enough to write all the file content data to the device.
2457 Meta-information, like the modification time etc., are not that important
2458 and leaving such information uncommitted does not prevent a successful
2459 recovery of the file in case of a problem.
2461 @deftypefun int fdatasync (int @var{fildes})
2462 @standards{POSIX, unistd.h}
2463 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
2464 When a call to the @code{fdatasync} function returns, it is ensured
2465 that all of the file data is written to the device. For all pending I/O
2466 operations, the parts guaranteeing data integrity finished.
2468 Not all systems implement the @code{fdatasync} operation. On systems
2469 missing this functionality @code{fdatasync} is emulated by a call to
2470 @code{fsync} since the performed actions are a superset of those
2471 required by @code{fdatasync}.
2473 The prototype for @code{fdatasync} is in @file{unistd.h}.
2475 The return value of the function is zero if no error occurred. Otherwise
2476 it is @math{-1} and the global variable @code{errno} is set to the
2480 The descriptor @var{fildes} is not valid.
2483 No synchronization is possible since the system does not implement this.
2488 @node Asynchronous I/O
2489 @section Perform I/O Operations in Parallel
2491 The POSIX.1b standard defines a new set of I/O operations which can
2492 significantly reduce the time an application spends waiting for I/O. The
2493 new functions allow a program to initiate one or more I/O operations and
2494 then immediately resume normal work while the I/O operations are
2495 executed in parallel. This functionality is available if the
2496 @file{unistd.h} file defines the symbol @code{_POSIX_ASYNCHRONOUS_IO}.
2498 These functions are part of the library with realtime functions named
2499 @file{librt}. They are not actually part of the @file{libc} binary.
2500 The implementation of these functions can be done using support in the
2501 kernel (if available) or using an implementation based on threads at
2502 userlevel. In the latter case it might be necessary to link applications
2503 with the thread library @file{libpthread} in addition to @file{librt}.
2505 All AIO operations operate on files which were opened previously. There
2506 might be arbitrarily many operations running for one file. The
2507 asynchronous I/O operations are controlled using a data structure named
2508 @code{struct aiocb} (@dfn{AIO control block}). It is defined in
2509 @file{aio.h} as follows.
2511 @deftp {Data Type} {struct aiocb}
2512 @standards{POSIX.1b, aio.h}
2513 The POSIX.1b standard mandates that the @code{struct aiocb} structure
2514 contains at least the members described in the following table. There
2515 might be more elements which are used by the implementation, but
2516 depending upon these elements is not portable and is highly deprecated.
2519 @item int aio_fildes
2520 This element specifies the file descriptor to be used for the
2521 operation. It must be a legal descriptor, otherwise the operation will
2524 The device on which the file is opened must allow the seek operation.
2525 I.e., it is not possible to use any of the AIO operations on devices
2526 like terminals where an @code{lseek} call would lead to an error.
2528 @item off_t aio_offset
2529 This element specifies the offset in the file at which the operation (input
2530 or output) is performed. Since the operations are carried out in arbitrary
2531 order and more than one operation for one file descriptor can be
2532 started, one cannot expect a current read/write position of the file
2535 @item volatile void *aio_buf
2536 This is a pointer to the buffer with the data to be written or the place
2537 where the read data is stored.
2539 @item size_t aio_nbytes
2540 This element specifies the length of the buffer pointed to by @code{aio_buf}.
2542 @item int aio_reqprio
2543 If the platform has defined @code{_POSIX_PRIORITIZED_IO} and
2544 @code{_POSIX_PRIORITY_SCHEDULING}, the AIO requests are
2545 processed based on the current scheduling priority. The
2546 @code{aio_reqprio} element can then be used to lower the priority of the
2549 @item struct sigevent aio_sigevent
2550 This element specifies how the calling process is notified once the
2551 operation terminates. If the @code{sigev_notify} element is
2552 @code{SIGEV_NONE}, no notification is sent. If it is @code{SIGEV_SIGNAL},
2553 the signal determined by @code{sigev_signo} is sent. Otherwise,
2554 @code{sigev_notify} must be @code{SIGEV_THREAD}. In this case, a thread
2555 is created which starts executing the function pointed to by
2556 @code{sigev_notify_function}.
2558 @item int aio_lio_opcode
2559 This element is only used by the @code{lio_listio} and
2560 @code{lio_listio64} functions. Since these functions allow an
2561 arbitrary number of operations to start at once, and each operation can be
2562 input or output (or nothing), the information must be stored in the
2563 control block. The possible values are:
2567 Start a read operation. Read from the file at position
2568 @code{aio_offset} and store the next @code{aio_nbytes} bytes in the
2569 buffer pointed to by @code{aio_buf}.
2572 Start a write operation. Write @code{aio_nbytes} bytes starting at
2573 @code{aio_buf} into the file starting at position @code{aio_offset}.
2576 Do nothing for this control block. This value is useful sometimes when
2577 an array of @code{struct aiocb} values contains holes, i.e., some of the
2578 values must not be handled although the whole array is presented to the
2579 @code{lio_listio} function.
2583 When the sources are compiled using @code{_FILE_OFFSET_BITS == 64} on a
2584 32 bit machine, this type is in fact @code{struct aiocb64}, since the LFS
2585 interface transparently replaces the @code{struct aiocb} definition.
2588 For use with the AIO functions defined in the LFS, there is a similar type
2589 defined which replaces the types of the appropriate members with larger
2590 types but otherwise is equivalent to @code{struct aiocb}. Particularly,
2591 all member names are the same.
2593 @deftp {Data Type} {struct aiocb64}
2594 @standards{POSIX.1b, aio.h}
2596 @item int aio_fildes
2597 This element specifies the file descriptor which is used for the
2598 operation. It must be a legal descriptor since otherwise the operation
2599 fails for obvious reasons.
2601 The device on which the file is opened must allow the seek operation.
2602 I.e., it is not possible to use any of the AIO operations on devices
2603 like terminals where an @code{lseek} call would lead to an error.
2605 @item off64_t aio_offset
2606 This element specifies at which offset in the file the operation (input
2607 or output) is performed. Since the operation are carried in arbitrary
2608 order and more than one operation for one file descriptor can be
2609 started, one cannot expect a current read/write position of the file
2612 @item volatile void *aio_buf
2613 This is a pointer to the buffer with the data to be written or the place
2614 where the read data is stored.
2616 @item size_t aio_nbytes
2617 This element specifies the length of the buffer pointed to by @code{aio_buf}.
2619 @item int aio_reqprio
2620 If for the platform @code{_POSIX_PRIORITIZED_IO} and
2621 @code{_POSIX_PRIORITY_SCHEDULING} are defined the AIO requests are
2622 processed based on the current scheduling priority. The
2623 @code{aio_reqprio} element can then be used to lower the priority of the
2626 @item struct sigevent aio_sigevent
2627 This element specifies how the calling process is notified once the
2628 operation terminates. If the @code{sigev_notify} element is
2629 @code{SIGEV_NONE} no notification is sent. If it is @code{SIGEV_SIGNAL},
2630 the signal determined by @code{sigev_signo} is sent. Otherwise,
2631 @code{sigev_notify} must be @code{SIGEV_THREAD} in which case a thread
2632 is created which starts executing the function pointed to by
2633 @code{sigev_notify_function}.
2635 @item int aio_lio_opcode
2636 This element is only used by the @code{lio_listio} and
2637 @code{lio_listio64} functions. Since these functions allow an
2638 arbitrary number of operations to start at once, and since each operation can be
2639 input or output (or nothing), the information must be stored in the
2640 control block. See the description of @code{struct aiocb} for a description
2641 of the possible values.
2644 When the sources are compiled using @code{_FILE_OFFSET_BITS == 64} on a
2645 32 bit machine, this type is available under the name @code{struct
2646 aiocb64}, since the LFS transparently replaces the old interface.
2650 * Asynchronous Reads/Writes:: Asynchronous Read and Write Operations.
2651 * Status of AIO Operations:: Getting the Status of AIO Operations.
2652 * Synchronizing AIO Operations:: Getting into a consistent state.
2653 * Cancel AIO Operations:: Cancellation of AIO Operations.
2654 * Configuration of AIO:: How to optimize the AIO implementation.
2657 @node Asynchronous Reads/Writes
2658 @subsection Asynchronous Read and Write Operations
2660 @deftypefun int aio_read (struct aiocb *@var{aiocbp})
2661 @standards{POSIX.1b, aio.h}
2662 @safety{@prelim{}@mtsafe{}@asunsafe{@asulock{} @ascuheap{}}@acunsafe{@aculock{} @acsmem{}}}
2663 @c Calls aio_enqueue_request.
2664 @c aio_enqueue_request @asulock @ascuheap @aculock @acsmem
2666 @c pthread_getschedparam @asulock @aculock
2667 @c lll_lock (pthread descriptor's lock) @asulock @aculock
2668 @c sched_getparam ok
2669 @c sched_getscheduler ok
2670 @c lll_unlock @aculock
2671 @c pthread_mutex_lock (aio_requests_mutex) @asulock @aculock
2672 @c get_elem @ascuheap @acsmem [@asucorrupt @acucorrupt]
2673 @c realloc @ascuheap @acsmem
2674 @c calloc @ascuheap @acsmem
2675 @c aio_create_helper_thread @asulock @ascuheap @aculock @acsmem
2676 @c pthread_attr_init ok
2677 @c pthread_attr_setdetachstate ok
2678 @c pthread_get_minstack ok
2679 @c pthread_attr_setstacksize ok
2683 @c SYSCALL rt_sigprocmask ok
2684 @c pthread_create @asulock @ascuheap @aculock @acsmem
2685 @c lll_lock (default_pthread_attr_lock) @asulock @aculock
2686 @c alloca/malloc @ascuheap @acsmem
2687 @c lll_unlock @aculock
2688 @c allocate_stack @asulock @ascuheap @aculock @acsmem
2690 @c lll_lock (default_pthread_attr_lock) @asulock @aculock
2691 @c lll_unlock @aculock
2692 @c _dl_allocate_tls @ascuheap @acsmem
2693 @c _dl_allocate_tls_storage @ascuheap @acsmem
2694 @c memalign @ascuheap @acsmem
2697 @c free @ascuheap @acsmem
2698 @c allocate_dtv @ascuheap @acsmem
2699 @c calloc @ascuheap @acsmem
2703 @c lll_lock (stack_cache_lock) @asulock @aculock
2707 @c stack_list_del dup
2708 @c stack_list_add dup
2709 @c lll_unlock @aculock
2710 @c _dl_allocate_tls_init ok
2713 @c atomic_fetch_add_relaxed ok
2715 @c change_stack_perm ok
2718 @c stack_list_del dup
2719 @c _dl_deallocate_tls dup
2721 @c THREAD_COPY_STACK_GUARD ok
2722 @c THREAD_COPY_POINTER_GUARD ok
2723 @c atomic_exchange_acquire ok
2724 @c lll_futex_wake ok
2725 @c deallocate_stack @asulock @ascuheap @aculock @acsmem
2726 @c lll_lock (state_cache_lock) @asulock @aculock
2727 @c stack_list_del ok
2728 @c atomic_write_barrier ok
2730 @c atomic_write_barrier ok
2731 @c queue_stack @ascuheap @acsmem
2732 @c stack_list_add ok
2733 @c atomic_write_barrier ok
2735 @c atomic_write_barrier ok
2736 @c free_stacks @ascuheap @acsmem
2737 @c list_for_each_prev_safe ok
2740 @c stack_list_del dup
2741 @c _dl_deallocate_tls dup
2743 @c _dl_deallocate_tls @ascuheap @acsmem
2744 @c free @ascuheap @acsmem
2745 @c lll_unlock @aculock
2746 @c create_thread @asulock @ascuheap @aculock @acsmem
2749 @c do_clone @asulock @ascuheap @aculock @acsmem
2750 @c PREPARE_CREATE ok
2751 @c lll_lock (pd->lock) @asulock @aculock
2752 @c atomic_fetch_add_relaxed ok
2754 @c atomic_fetch_add_relaxed ok
2755 @c atomic_exchange_acquire ok
2756 @c lll_futex_wake ok
2757 @c deallocate_stack dup
2758 @c sched_setaffinity ok
2760 @c sched_setscheduler ok
2761 @c atomic_compare_and_exchange_bool_acq ok
2762 @c nptl_create_event ok
2763 @c lll_unlock (pd->lock) @aculock
2764 @c free @ascuheap @acsmem
2765 @c pthread_attr_destroy ok (cpuset won't be set, so free isn't called)
2766 @c add_request_to_runlist ok
2767 @c pthread_cond_signal ok
2768 @c aio_free_request ok
2769 @c pthread_mutex_unlock @aculock
2771 @c (in the new thread, initiated with clone)
2774 @c ctype_init @mtslocale
2775 @c atomic_exchange_acquire ok
2776 @c lll_futex_wake ok
2780 @c LIBC_CANCEL_ASYNC -> __pthread_enable_asynccancel ok
2782 @c pthread_unwind ok
2783 @c Unwind_ForcedUnwind or longjmp ok [@ascuheap @acsmem?]
2784 @c lll_lock @asulock @aculock
2785 @c lll_unlock @asulock @aculock
2786 @c LIBC_CANCEL_RESET -> __pthread_disable_asynccancel ok
2787 @c lll_futex_wait ok
2788 @c ->start_routine ok -----
2789 @c call_tls_dtors @asulock @ascuheap @aculock @acsmem
2790 @c user-supplied dtor
2791 @c rtld_lock_lock_recursive (dl_load_lock) @asulock @aculock
2792 @c rtld_lock_unlock_recursive @aculock
2793 @c free @ascuheap @acsmem
2794 @c nptl_deallocate_tsd @ascuheap @acsmem
2795 @c tsd user-supplied dtors ok
2796 @c free @ascuheap @acsmem
2797 @c libc_thread_freeres
2798 @c libc_thread_subfreeres ok
2799 @c atomic_fetch_add_relaxed ok
2802 @c atomic_compare_exchange_bool_acq ok
2803 @c nptl_death_event ok
2804 @c lll_robust_dead ok
2807 @c free_tcb @asulock @ascuheap @aculock @acsmem
2808 @c free @ascuheap @acsmem
2809 @c deallocate_stack @asulock @ascuheap @aculock @acsmem
2810 @c lll_futex_wait ok
2811 @c exit_thread_inline ok
2814 This function initiates an asynchronous read operation. It
2815 immediately returns after the operation was enqueued or when an
2816 error was encountered.
2818 The first @code{aiocbp->aio_nbytes} bytes of the file for which
2819 @code{aiocbp->aio_fildes} is a descriptor are written to the buffer
2820 starting at @code{aiocbp->aio_buf}. Reading starts at the absolute
2821 position @code{aiocbp->aio_offset} in the file.
2823 If prioritized I/O is supported by the platform the
2824 @code{aiocbp->aio_reqprio} value is used to adjust the priority before
2825 the request is actually enqueued.
2827 The calling process is notified about the termination of the read
2828 request according to the @code{aiocbp->aio_sigevent} value.
2830 When @code{aio_read} returns, the return value is zero if no error
2831 occurred that can be found before the process is enqueued. If such an
2832 early error is found, the function returns @math{-1} and sets
2833 @code{errno} to one of the following values:
2837 The request was not enqueued due to (temporarily) exceeded resource
2840 The @code{aio_read} function is not implemented.
2842 The @code{aiocbp->aio_fildes} descriptor is not valid. This condition
2843 need not be recognized before enqueueing the request and so this error
2844 might also be signaled asynchronously.
2846 The @code{aiocbp->aio_offset} or @code{aiocbp->aio_reqpiro} value is
2847 invalid. This condition need not be recognized before enqueueing the
2848 request and so this error might also be signaled asynchronously.
2851 If @code{aio_read} returns zero, the current status of the request
2852 can be queried using @code{aio_error} and @code{aio_return} functions.
2853 As long as the value returned by @code{aio_error} is @code{EINPROGRESS}
2854 the operation has not yet completed. If @code{aio_error} returns zero,
2855 the operation successfully terminated, otherwise the value is to be
2856 interpreted as an error code. If the function terminated, the result of
2857 the operation can be obtained using a call to @code{aio_return}. The
2858 returned value is the same as an equivalent call to @code{read} would
2859 have returned. Possible error codes returned by @code{aio_error} are:
2863 The @code{aiocbp->aio_fildes} descriptor is not valid.
2865 The operation was canceled before the operation was finished
2866 (@pxref{Cancel AIO Operations})
2868 The @code{aiocbp->aio_offset} value is invalid.
2871 When the sources are compiled with @code{_FILE_OFFSET_BITS == 64} this
2872 function is in fact @code{aio_read64} since the LFS interface transparently
2873 replaces the normal implementation.
2876 @deftypefun int aio_read64 (struct aiocb64 *@var{aiocbp})
2877 @standards{Unix98, aio.h}
2878 @safety{@prelim{}@mtsafe{}@asunsafe{@asulock{} @ascuheap{}}@acunsafe{@aculock{} @acsmem{}}}
2879 This function is similar to the @code{aio_read} function. The only
2880 difference is that on @w{32 bit} machines, the file descriptor should
2881 be opened in the large file mode. Internally, @code{aio_read64} uses
2882 functionality equivalent to @code{lseek64} (@pxref{File Position
2883 Primitive}) to position the file descriptor correctly for the reading,
2884 as opposed to the @code{lseek} functionality used in @code{aio_read}.
2886 When the sources are compiled with @code{_FILE_OFFSET_BITS == 64}, this
2887 function is available under the name @code{aio_read} and so transparently
2888 replaces the interface for small files on 32 bit machines.
2891 To write data asynchronously to a file, there exists an equivalent pair
2892 of functions with a very similar interface.
2894 @deftypefun int aio_write (struct aiocb *@var{aiocbp})
2895 @standards{POSIX.1b, aio.h}
2896 @safety{@prelim{}@mtsafe{}@asunsafe{@asulock{} @ascuheap{}}@acunsafe{@aculock{} @acsmem{}}}
2897 This function initiates an asynchronous write operation. The function
2898 call immediately returns after the operation was enqueued or if before
2899 this happens an error was encountered.
2901 The first @code{aiocbp->aio_nbytes} bytes from the buffer starting at
2902 @code{aiocbp->aio_buf} are written to the file for which
2903 @code{aiocbp->aio_fildes} is a descriptor, starting at the absolute
2904 position @code{aiocbp->aio_offset} in the file.
2906 If prioritized I/O is supported by the platform, the
2907 @code{aiocbp->aio_reqprio} value is used to adjust the priority before
2908 the request is actually enqueued.
2910 The calling process is notified about the termination of the read
2911 request according to the @code{aiocbp->aio_sigevent} value.
2913 When @code{aio_write} returns, the return value is zero if no error
2914 occurred that can be found before the process is enqueued. If such an
2915 early error is found the function returns @math{-1} and sets
2916 @code{errno} to one of the following values.
2920 The request was not enqueued due to (temporarily) exceeded resource
2923 The @code{aio_write} function is not implemented.
2925 The @code{aiocbp->aio_fildes} descriptor is not valid. This condition
2926 may not be recognized before enqueueing the request, and so this error
2927 might also be signaled asynchronously.
2929 The @code{aiocbp->aio_offset} or @code{aiocbp->aio_reqprio} value is
2930 invalid. This condition may not be recognized before enqueueing the
2931 request and so this error might also be signaled asynchronously.
2934 In the case @code{aio_write} returns zero, the current status of the
2935 request can be queried using the @code{aio_error} and @code{aio_return}
2936 functions. As long as the value returned by @code{aio_error} is
2937 @code{EINPROGRESS} the operation has not yet completed. If
2938 @code{aio_error} returns zero, the operation successfully terminated,
2939 otherwise the value is to be interpreted as an error code. If the
2940 function terminated, the result of the operation can be obtained using a call
2941 to @code{aio_return}. The returned value is the same as an equivalent
2942 call to @code{read} would have returned. Possible error codes returned
2943 by @code{aio_error} are:
2947 The @code{aiocbp->aio_fildes} descriptor is not valid.
2949 The operation was canceled before the operation was finished.
2950 (@pxref{Cancel AIO Operations})
2952 The @code{aiocbp->aio_offset} value is invalid.
2955 When the sources are compiled with @code{_FILE_OFFSET_BITS == 64}, this
2956 function is in fact @code{aio_write64} since the LFS interface transparently
2957 replaces the normal implementation.
2960 @deftypefun int aio_write64 (struct aiocb64 *@var{aiocbp})
2961 @standards{Unix98, aio.h}
2962 @safety{@prelim{}@mtsafe{}@asunsafe{@asulock{} @ascuheap{}}@acunsafe{@aculock{} @acsmem{}}}
2963 This function is similar to the @code{aio_write} function. The only
2964 difference is that on @w{32 bit} machines the file descriptor should
2965 be opened in the large file mode. Internally @code{aio_write64} uses
2966 functionality equivalent to @code{lseek64} (@pxref{File Position
2967 Primitive}) to position the file descriptor correctly for the writing,
2968 as opposed to the @code{lseek} functionality used in @code{aio_write}.
2970 When the sources are compiled with @code{_FILE_OFFSET_BITS == 64}, this
2971 function is available under the name @code{aio_write} and so transparently
2972 replaces the interface for small files on 32 bit machines.
2975 Besides these functions with the more or less traditional interface,
2976 POSIX.1b also defines a function which can initiate more than one
2977 operation at a time, and which can handle freely mixed read and write
2978 operations. It is therefore similar to a combination of @code{readv} and
2981 @deftypefun int lio_listio (int @var{mode}, struct aiocb *const @var{list}[], int @var{nent}, struct sigevent *@var{sig})
2982 @standards{POSIX.1b, aio.h}
2983 @safety{@prelim{}@mtsafe{}@asunsafe{@asulock{} @ascuheap{}}@acunsafe{@aculock{} @acsmem{}}}
2984 @c Call lio_listio_internal, that takes the aio_requests_mutex lock and
2985 @c enqueues each request. Then, it waits for notification or prepares
2986 @c for it before releasing the lock. Even though it performs memory
2987 @c allocation and locking of its own, it doesn't add any classes of
2988 @c safety issues that aren't already covered by aio_enqueue_request.
2989 The @code{lio_listio} function can be used to enqueue an arbitrary
2990 number of read and write requests at one time. The requests can all be
2991 meant for the same file, all for different files or every solution in
2994 @code{lio_listio} gets the @var{nent} requests from the array pointed to
2995 by @var{list}. The operation to be performed is determined by the
2996 @code{aio_lio_opcode} member in each element of @var{list}. If this
2997 field is @code{LIO_READ} a read operation is enqueued, similar to a call
2998 of @code{aio_read} for this element of the array (except that the way
2999 the termination is signalled is different, as we will see below). If
3000 the @code{aio_lio_opcode} member is @code{LIO_WRITE} a write operation
3001 is enqueued. Otherwise the @code{aio_lio_opcode} must be @code{LIO_NOP}
3002 in which case this element of @var{list} is simply ignored. This
3003 ``operation'' is useful in situations where one has a fixed array of
3004 @code{struct aiocb} elements from which only a few need to be handled at
3005 a time. Another situation is where the @code{lio_listio} call was
3006 canceled before all requests are processed (@pxref{Cancel AIO
3007 Operations}) and the remaining requests have to be reissued.
3009 The other members of each element of the array pointed to by
3010 @code{list} must have values suitable for the operation as described in
3011 the documentation for @code{aio_read} and @code{aio_write} above.
3013 The @var{mode} argument determines how @code{lio_listio} behaves after
3014 having enqueued all the requests. If @var{mode} is @code{LIO_WAIT} it
3015 waits until all requests terminated. Otherwise @var{mode} must be
3016 @code{LIO_NOWAIT} and in this case the function returns immediately after
3017 having enqueued all the requests. In this case the caller gets a
3018 notification of the termination of all requests according to the
3019 @var{sig} parameter. If @var{sig} is @code{NULL} no notification is
3020 sent. Otherwise a signal is sent or a thread is started, just as
3021 described in the description for @code{aio_read} or @code{aio_write}.
3023 If @var{mode} is @code{LIO_WAIT}, the return value of @code{lio_listio}
3024 is @math{0} when all requests completed successfully. Otherwise the
3025 function returns @math{-1} and @code{errno} is set accordingly. To find
3026 out which request or requests failed one has to use the @code{aio_error}
3027 function on all the elements of the array @var{list}.
3029 In case @var{mode} is @code{LIO_NOWAIT}, the function returns @math{0} if
3030 all requests were enqueued correctly. The current state of the requests
3031 can be found using @code{aio_error} and @code{aio_return} as described
3032 above. If @code{lio_listio} returns @math{-1} in this mode, the
3033 global variable @code{errno} is set accordingly. If a request did not
3034 yet terminate, a call to @code{aio_error} returns @code{EINPROGRESS}. If
3035 the value is different, the request is finished and the error value (or
3036 @math{0}) is returned and the result of the operation can be retrieved
3037 using @code{aio_return}.
3039 Possible values for @code{errno} are:
3043 The resources necessary to queue all the requests are not available at
3044 the moment. The error status for each element of @var{list} must be
3045 checked to determine which request failed.
3047 Another reason could be that the system wide limit of AIO requests is
3048 exceeded. This cannot be the case for the implementation on @gnusystems{}
3049 since no arbitrary limits exist.
3051 The @var{mode} parameter is invalid or @var{nent} is larger than
3052 @code{AIO_LISTIO_MAX}.
3054 One or more of the request's I/O operations failed. The error status of
3055 each request should be checked to determine which one failed.
3057 The @code{lio_listio} function is not supported.
3060 If the @var{mode} parameter is @code{LIO_NOWAIT} and the caller cancels
3061 a request, the error status for this request returned by
3062 @code{aio_error} is @code{ECANCELED}.
3064 When the sources are compiled with @code{_FILE_OFFSET_BITS == 64}, this
3065 function is in fact @code{lio_listio64} since the LFS interface
3066 transparently replaces the normal implementation.
3069 @deftypefun int lio_listio64 (int @var{mode}, struct aiocb64 *const @var{list}[], int @var{nent}, struct sigevent *@var{sig})
3070 @standards{Unix98, aio.h}
3071 @safety{@prelim{}@mtsafe{}@asunsafe{@asulock{} @ascuheap{}}@acunsafe{@aculock{} @acsmem{}}}
3072 This function is similar to the @code{lio_listio} function. The only
3073 difference is that on @w{32 bit} machines, the file descriptor should
3074 be opened in the large file mode. Internally, @code{lio_listio64} uses
3075 functionality equivalent to @code{lseek64} (@pxref{File Position
3076 Primitive}) to position the file descriptor correctly for the reading or
3077 writing, as opposed to the @code{lseek} functionality used in
3080 When the sources are compiled with @code{_FILE_OFFSET_BITS == 64}, this
3081 function is available under the name @code{lio_listio} and so
3082 transparently replaces the interface for small files on 32 bit
3086 @node Status of AIO Operations
3087 @subsection Getting the Status of AIO Operations
3089 As already described in the documentation of the functions in the last
3090 section, it must be possible to get information about the status of an I/O
3091 request. When the operation is performed truly asynchronously (as with
3092 @code{aio_read} and @code{aio_write} and with @code{lio_listio} when the
3093 mode is @code{LIO_NOWAIT}), one sometimes needs to know whether a
3094 specific request already terminated and if so, what the result was.
3095 The following two functions allow you to get this kind of information.
3097 @deftypefun int aio_error (const struct aiocb *@var{aiocbp})
3098 @standards{POSIX.1b, aio.h}
3099 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
3100 This function determines the error state of the request described by the
3101 @code{struct aiocb} variable pointed to by @var{aiocbp}. If the
3102 request has not yet terminated the value returned is always
3103 @code{EINPROGRESS}. Once the request has terminated the value
3104 @code{aio_error} returns is either @math{0} if the request completed
3105 successfully or it returns the value which would be stored in the
3106 @code{errno} variable if the request would have been done using
3107 @code{read}, @code{write}, or @code{fsync}.
3109 The function can return @code{ENOSYS} if it is not implemented. It
3110 could also return @code{EINVAL} if the @var{aiocbp} parameter does not
3111 refer to an asynchronous operation whose return status is not yet known.
3113 When the sources are compiled with @code{_FILE_OFFSET_BITS == 64} this
3114 function is in fact @code{aio_error64} since the LFS interface
3115 transparently replaces the normal implementation.
3118 @deftypefun int aio_error64 (const struct aiocb64 *@var{aiocbp})
3119 @standards{Unix98, aio.h}
3120 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
3121 This function is similar to @code{aio_error} with the only difference
3122 that the argument is a reference to a variable of type @code{struct
3125 When the sources are compiled with @code{_FILE_OFFSET_BITS == 64} this
3126 function is available under the name @code{aio_error} and so
3127 transparently replaces the interface for small files on 32 bit
3131 @deftypefun ssize_t aio_return (struct aiocb *@var{aiocbp})
3132 @standards{POSIX.1b, aio.h}
3133 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
3134 This function can be used to retrieve the return status of the operation
3135 carried out by the request described in the variable pointed to by
3136 @var{aiocbp}. As long as the error status of this request as returned
3137 by @code{aio_error} is @code{EINPROGRESS} the return value of this function is
3140 Once the request is finished this function can be used exactly once to
3141 retrieve the return value. Following calls might lead to undefined
3142 behavior. The return value itself is the value which would have been
3143 returned by the @code{read}, @code{write}, or @code{fsync} call.
3145 The function can return @code{ENOSYS} if it is not implemented. It
3146 could also return @code{EINVAL} if the @var{aiocbp} parameter does not
3147 refer to an asynchronous operation whose return status is not yet known.
3149 When the sources are compiled with @code{_FILE_OFFSET_BITS == 64} this
3150 function is in fact @code{aio_return64} since the LFS interface
3151 transparently replaces the normal implementation.
3154 @deftypefun ssize_t aio_return64 (struct aiocb64 *@var{aiocbp})
3155 @standards{Unix98, aio.h}
3156 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
3157 This function is similar to @code{aio_return} with the only difference
3158 that the argument is a reference to a variable of type @code{struct
3161 When the sources are compiled with @code{_FILE_OFFSET_BITS == 64} this
3162 function is available under the name @code{aio_return} and so
3163 transparently replaces the interface for small files on 32 bit
3167 @node Synchronizing AIO Operations
3168 @subsection Getting into a Consistent State
3170 When dealing with asynchronous operations it is sometimes necessary to
3171 get into a consistent state. This would mean for AIO that one wants to
3172 know whether a certain request or a group of requests were processed.
3173 This could be done by waiting for the notification sent by the system
3174 after the operation terminated, but this sometimes would mean wasting
3175 resources (mainly computation time). Instead POSIX.1b defines two
3176 functions which will help with most kinds of consistency.
3178 The @code{aio_fsync} and @code{aio_fsync64} functions are only available
3179 if the symbol @code{_POSIX_SYNCHRONIZED_IO} is defined in @file{unistd.h}.
3181 @cindex synchronizing
3182 @deftypefun int aio_fsync (int @var{op}, struct aiocb *@var{aiocbp})
3183 @standards{POSIX.1b, aio.h}
3184 @safety{@prelim{}@mtsafe{}@asunsafe{@asulock{} @ascuheap{}}@acunsafe{@aculock{} @acsmem{}}}
3185 @c After fcntl to check that the FD is open, it calls
3186 @c aio_enqueue_request.
3187 Calling this function forces all I/O operations queued at the
3188 time of the function call operating on the file descriptor
3189 @code{aiocbp->aio_fildes} into the synchronized I/O completion state
3190 (@pxref{Synchronizing I/O}). The @code{aio_fsync} function returns
3191 immediately but the notification through the method described in
3192 @code{aiocbp->aio_sigevent} will happen only after all requests for this
3193 file descriptor have terminated and the file is synchronized. This also
3194 means that requests for this very same file descriptor which are queued
3195 after the synchronization request are not affected.
3197 If @var{op} is @code{O_DSYNC} the synchronization happens as with a call
3198 to @code{fdatasync}. Otherwise @var{op} should be @code{O_SYNC} and
3199 the synchronization happens as with @code{fsync}.
3201 As long as the synchronization has not happened, a call to
3202 @code{aio_error} with the reference to the object pointed to by
3203 @var{aiocbp} returns @code{EINPROGRESS}. Once the synchronization is
3204 done @code{aio_error} return @math{0} if the synchronization was not
3205 successful. Otherwise the value returned is the value to which the
3206 @code{fsync} or @code{fdatasync} function would have set the
3207 @code{errno} variable. In this case nothing can be assumed about the
3208 consistency of the data written to this file descriptor.
3210 The return value of this function is @math{0} if the request was
3211 successfully enqueued. Otherwise the return value is @math{-1} and
3212 @code{errno} is set to one of the following values:
3216 The request could not be enqueued due to temporary lack of resources.
3218 The file descriptor @code{@var{aiocbp}->aio_fildes} is not valid.
3220 The implementation does not support I/O synchronization or the @var{op}
3221 parameter is other than @code{O_DSYNC} and @code{O_SYNC}.
3223 This function is not implemented.
3226 When the sources are compiled with @code{_FILE_OFFSET_BITS == 64} this
3227 function is in fact @code{aio_fsync64} since the LFS interface
3228 transparently replaces the normal implementation.
3231 @deftypefun int aio_fsync64 (int @var{op}, struct aiocb64 *@var{aiocbp})
3232 @standards{Unix98, aio.h}
3233 @safety{@prelim{}@mtsafe{}@asunsafe{@asulock{} @ascuheap{}}@acunsafe{@aculock{} @acsmem{}}}
3234 This function is similar to @code{aio_fsync} with the only difference
3235 that the argument is a reference to a variable of type @code{struct
3238 When the sources are compiled with @code{_FILE_OFFSET_BITS == 64} this
3239 function is available under the name @code{aio_fsync} and so
3240 transparently replaces the interface for small files on 32 bit
3244 Another method of synchronization is to wait until one or more requests of a
3245 specific set terminated. This could be achieved by the @code{aio_*}
3246 functions to notify the initiating process about the termination but in
3247 some situations this is not the ideal solution. In a program which
3248 constantly updates clients somehow connected to the server it is not
3249 always the best solution to go round robin since some connections might
3250 be slow. On the other hand letting the @code{aio_*} functions notify the
3251 caller might also be not the best solution since whenever the process
3252 works on preparing data for a client it makes no sense to be
3253 interrupted by a notification since the new client will not be handled
3254 before the current client is served. For situations like this
3255 @code{aio_suspend} should be used.
3257 @deftypefun int aio_suspend (const struct aiocb *const @var{list}[], int @var{nent}, const struct timespec *@var{timeout})
3258 @standards{POSIX.1b, aio.h}
3259 @safety{@prelim{}@mtsafe{}@asunsafe{@asulock{}}@acunsafe{@aculock{}}}
3260 @c Take aio_requests_mutex, set up waitlist and requestlist, wait
3261 @c for completion or timeout, and release the mutex.
3262 When calling this function, the calling thread is suspended until at
3263 least one of the requests pointed to by the @var{nent} elements of the
3264 array @var{list} has completed. If any of the requests has already
3265 completed at the time @code{aio_suspend} is called, the function returns
3266 immediately. Whether a request has terminated or not is determined by
3267 comparing the error status of the request with @code{EINPROGRESS}. If
3268 an element of @var{list} is @code{NULL}, the entry is simply ignored.
3270 If no request has finished, the calling process is suspended. If
3271 @var{timeout} is @code{NULL}, the process is not woken until a request
3272 has finished. If @var{timeout} is not @code{NULL}, the process remains
3273 suspended at least as long as specified in @var{timeout}. In this case,
3274 @code{aio_suspend} returns with an error.
3276 The return value of the function is @math{0} if one or more requests
3277 from the @var{list} have terminated. Otherwise the function returns
3278 @math{-1} and @code{errno} is set to one of the following values:
3282 None of the requests from the @var{list} completed in the time specified
3285 A signal interrupted the @code{aio_suspend} function. This signal might
3286 also be sent by the AIO implementation while signalling the termination
3287 of one of the requests.
3289 The @code{aio_suspend} function is not implemented.
3292 When the sources are compiled with @code{_FILE_OFFSET_BITS == 64} this
3293 function is in fact @code{aio_suspend64} since the LFS interface
3294 transparently replaces the normal implementation.
3297 @deftypefun int aio_suspend64 (const struct aiocb64 *const @var{list}[], int @var{nent}, const struct timespec *@var{timeout})
3298 @standards{Unix98, aio.h}
3299 @safety{@prelim{}@mtsafe{}@asunsafe{@asulock{}}@acunsafe{@aculock{}}}
3300 This function is similar to @code{aio_suspend} with the only difference
3301 that the argument is a reference to a variable of type @code{struct
3304 When the sources are compiled with @code{_FILE_OFFSET_BITS == 64} this
3305 function is available under the name @code{aio_suspend} and so
3306 transparently replaces the interface for small files on 32 bit
3310 @node Cancel AIO Operations
3311 @subsection Cancellation of AIO Operations
3313 When one or more requests are asynchronously processed, it might be
3314 useful in some situations to cancel a selected operation, e.g., if it
3315 becomes obvious that the written data is no longer accurate and would
3316 have to be overwritten soon. As an example, assume an application, which
3317 writes data in files in a situation where new incoming data would have
3318 to be written in a file which will be updated by an enqueued request.
3319 The POSIX AIO implementation provides such a function, but this function
3320 is not capable of forcing the cancellation of the request. It is up to the
3321 implementation to decide whether it is possible to cancel the operation
3322 or not. Therefore using this function is merely a hint.
3324 @deftypefun int aio_cancel (int @var{fildes}, struct aiocb *@var{aiocbp})
3325 @standards{POSIX.1b, aio.h}
3326 @safety{@prelim{}@mtsafe{}@asunsafe{@asulock{} @ascuheap{}}@acunsafe{@aculock{} @acsmem{}}}
3327 @c After fcntl to check the fd is open, hold aio_requests_mutex, call
3328 @c aio_find_req_fd, aio_remove_request, then aio_notify and
3329 @c aio_free_request each request before releasing the lock.
3330 @c aio_notify calls aio_notify_only and free, besides cond signal or
3331 @c similar. aio_notify_only calls pthread_attr_init,
3332 @c pthread_attr_setdetachstate, malloc, pthread_create,
3333 @c notify_func_wrapper, aio_sigqueue, getpid, raise.
3334 @c notify_func_wraper calls aio_start_notify_thread, free and then the
3335 @c notifier function.
3336 The @code{aio_cancel} function can be used to cancel one or more
3337 outstanding requests. If the @var{aiocbp} parameter is @code{NULL}, the
3338 function tries to cancel all of the outstanding requests which would process
3339 the file descriptor @var{fildes} (i.e., whose @code{aio_fildes} member
3340 is @var{fildes}). If @var{aiocbp} is not @code{NULL}, @code{aio_cancel}
3341 attempts to cancel the specific request pointed to by @var{aiocbp}.
3343 For requests which were successfully canceled, the normal notification
3344 about the termination of the request should take place. I.e., depending
3345 on the @code{struct sigevent} object which controls this, nothing
3346 happens, a signal is sent or a thread is started. If the request cannot
3347 be canceled, it terminates the usual way after performing the operation.
3349 After a request is successfully canceled, a call to @code{aio_error} with
3350 a reference to this request as the parameter will return
3351 @code{ECANCELED} and a call to @code{aio_return} will return @math{-1}.
3352 If the request wasn't canceled and is still running the error status is
3353 still @code{EINPROGRESS}.
3355 The return value of the function is @code{AIO_CANCELED} if there were
3356 requests which haven't terminated and which were successfully canceled.
3357 If there is one or more requests left which couldn't be canceled, the
3358 return value is @code{AIO_NOTCANCELED}. In this case @code{aio_error}
3359 must be used to find out which of the, perhaps multiple, requests (if
3360 @var{aiocbp} is @code{NULL}) weren't successfully canceled. If all
3361 requests already terminated at the time @code{aio_cancel} is called the
3362 return value is @code{AIO_ALLDONE}.
3364 If an error occurred during the execution of @code{aio_cancel} the
3365 function returns @math{-1} and sets @code{errno} to one of the following
3370 The file descriptor @var{fildes} is not valid.
3372 @code{aio_cancel} is not implemented.
3375 When the sources are compiled with @code{_FILE_OFFSET_BITS == 64}, this
3376 function is in fact @code{aio_cancel64} since the LFS interface
3377 transparently replaces the normal implementation.
3380 @deftypefun int aio_cancel64 (int @var{fildes}, struct aiocb64 *@var{aiocbp})
3381 @standards{Unix98, aio.h}
3382 @safety{@prelim{}@mtsafe{}@asunsafe{@asulock{} @ascuheap{}}@acunsafe{@aculock{} @acsmem{}}}
3383 This function is similar to @code{aio_cancel} with the only difference
3384 that the argument is a reference to a variable of type @code{struct
3387 When the sources are compiled with @code{_FILE_OFFSET_BITS == 64}, this
3388 function is available under the name @code{aio_cancel} and so
3389 transparently replaces the interface for small files on 32 bit
3393 @node Configuration of AIO
3394 @subsection How to optimize the AIO implementation
3396 The POSIX standard does not specify how the AIO functions are
3397 implemented. They could be system calls, but it is also possible to
3398 emulate them at userlevel.
3400 At the time of writing, the available implementation is a user-level
3401 implementation which uses threads for handling the enqueued requests.
3402 While this implementation requires making some decisions about
3403 limitations, hard limitations are something best avoided
3404 in @theglibc{}. Therefore, @theglibc{} provides a means
3405 for tuning the AIO implementation according to the individual use.
3407 @deftp {Data Type} {struct aioinit}
3408 @standards{GNU, aio.h}
3409 This data type is used to pass the configuration or tunable parameters
3410 to the implementation. The program has to initialize the members of
3411 this struct and pass it to the implementation using the @code{aio_init}
3415 @item int aio_threads
3416 This member specifies the maximal number of threads which may be used
3419 This number provides an estimate on the maximal number of simultaneously
3423 @item int aio_usedba
3427 @item int aio_numusers
3429 @item int aio_reserved[2]
3434 @deftypefun void aio_init (const struct aioinit *@var{init})
3435 @standards{GNU, aio.h}
3436 @safety{@prelim{}@mtsafe{}@asunsafe{@asulock{}}@acunsafe{@aculock{}}}
3437 @c All changes to global objects are guarded by aio_requests_mutex.
3438 This function must be called before any other AIO function. Calling it
3439 is completely voluntary, as it is only meant to help the AIO
3440 implementation perform better.
3442 Before calling @code{aio_init}, the members of a variable of
3443 type @code{struct aioinit} must be initialized. Then a reference to
3444 this variable is passed as the parameter to @code{aio_init} which itself
3445 may or may not pay attention to the hints.
3447 The function has no return value and no error cases are defined. It is
3448 an extension which follows a proposal from the SGI implementation in
3449 @w{Irix 6}. It is not covered by POSIX.1b or Unix98.
3452 @node Control Operations
3453 @section Control Operations on Files
3455 @cindex control operations on files
3456 @cindex @code{fcntl} function
3457 This section describes how you can perform various other operations on
3458 file descriptors, such as inquiring about or setting flags describing
3459 the status of the file descriptor, manipulating record locks, and the
3460 like. All of these operations are performed by the function @code{fcntl}.
3462 The second argument to the @code{fcntl} function is a command that
3463 specifies which operation to perform. The function and macros that name
3464 various flags that are used with it are declared in the header file
3465 @file{fcntl.h}. Many of these flags are also used by the @code{open}
3466 function; see @ref{Opening and Closing Files}.
3469 @deftypefun int fcntl (int @var{filedes}, int @var{command}, @dots{})
3470 @standards{POSIX.1, fcntl.h}
3471 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
3472 The @code{fcntl} function performs the operation specified by
3473 @var{command} on the file descriptor @var{filedes}. Some commands
3474 require additional arguments to be supplied. These additional arguments
3475 and the return value and error conditions are given in the detailed
3476 descriptions of the individual commands.
3478 Briefly, here is a list of what the various commands are. For an
3479 exhaustive list of kernel-specific options, please see @xref{System
3484 Duplicate the file descriptor (return another file descriptor pointing
3485 to the same open file). @xref{Duplicating Descriptors}.
3488 Get flags associated with the file descriptor. @xref{Descriptor Flags}.
3491 Set flags associated with the file descriptor. @xref{Descriptor Flags}.
3494 Get flags associated with the open file. @xref{File Status Flags}.
3497 Set flags associated with the open file. @xref{File Status Flags}.
3500 Test a file lock. @xref{File Locks}.
3503 Set or clear a file lock. @xref{File Locks}.
3506 Like @code{F_SETLK}, but wait for completion. @xref{File Locks}.
3509 Test an open file description lock. @xref{Open File Description Locks}.
3513 Set or clear an open file description lock. @xref{Open File Description Locks}.
3517 Like @code{F_OFD_SETLK}, but block until lock is acquired.
3518 @xref{Open File Description Locks}. Specific to Linux.
3521 Get process or process group ID to receive @code{SIGIO} signals.
3522 @xref{Interrupt Input}.
3525 Set process or process group ID to receive @code{SIGIO} signals.
3526 @xref{Interrupt Input}.
3529 This function is a cancellation point in multi-threaded programs for the
3530 commands @code{F_SETLKW} (and the LFS analogous @code{F_SETLKW64}) and
3531 @code{F_OFD_SETLKW}. This is a problem if the thread allocates some
3532 resources (like memory, file descriptors, semaphores or whatever) at the time
3533 @code{fcntl} is called. If the thread gets canceled these resources stay
3534 allocated until the program ends. To avoid this calls to @code{fcntl} should
3535 be protected using cancellation handlers.
3536 @c ref pthread_cleanup_push / pthread_cleanup_pop
3540 @node Duplicating Descriptors
3541 @section Duplicating Descriptors
3543 @cindex duplicating file descriptors
3544 @cindex redirecting input and output
3546 You can @dfn{duplicate} a file descriptor, or allocate another file
3547 descriptor that refers to the same open file as the original. Duplicate
3548 descriptors share one file position and one set of file status flags
3549 (@pxref{File Status Flags}), but each has its own set of file descriptor
3550 flags (@pxref{Descriptor Flags}).
3552 The major use of duplicating a file descriptor is to implement
3553 @dfn{redirection} of input or output: that is, to change the
3554 file or pipe that a particular file descriptor corresponds to.
3556 You can perform this operation using the @code{fcntl} function with the
3557 @code{F_DUPFD} command, but there are also convenient functions
3558 @code{dup} and @code{dup2} for duplicating descriptors.
3562 The @code{fcntl} function and flags are declared in @file{fcntl.h},
3563 while prototypes for @code{dup} and @code{dup2} are in the header file
3566 @deftypefun int dup (int @var{old})
3567 @standards{POSIX.1, unistd.h}
3568 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
3569 This function copies descriptor @var{old} to the first available
3570 descriptor number (the first number not currently open). It is
3571 equivalent to @code{fcntl (@var{old}, F_DUPFD, 0)}.
3574 @deftypefun int dup2 (int @var{old}, int @var{new})
3575 @standards{POSIX.1, unistd.h}
3576 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
3577 This function copies the descriptor @var{old} to descriptor number
3580 If @var{old} is an invalid descriptor, then @code{dup2} does nothing; it
3581 does not close @var{new}. Otherwise, the new duplicate of @var{old}
3582 replaces any previous meaning of descriptor @var{new}, as if @var{new}
3585 If @var{old} and @var{new} are different numbers, and @var{old} is a
3586 valid descriptor number, then @code{dup2} is equivalent to:
3590 fcntl (@var{old}, F_DUPFD, @var{new})
3593 However, @code{dup2} does this atomically; there is no instant in the
3594 middle of calling @code{dup2} at which @var{new} is closed and not yet a
3595 duplicate of @var{old}.
3598 @deftypefun int dup3 (int @var{old}, int @var{new}, int @var{flags})
3599 @standards{Linux, unistd.h}
3600 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
3601 This function is the same as @code{dup2} but creates the new
3602 descriptor as if it had been opened with flags @var{flags}. The only
3603 allowed flag is @code{O_CLOEXEC}.
3606 @deftypevr Macro int F_DUPFD
3607 @standards{POSIX.1, fcntl.h}
3608 This macro is used as the @var{command} argument to @code{fcntl}, to
3609 copy the file descriptor given as the first argument.
3611 The form of the call in this case is:
3614 fcntl (@var{old}, F_DUPFD, @var{next-filedes})
3617 The @var{next-filedes} argument is of type @code{int} and specifies that
3618 the file descriptor returned should be the next available one greater
3619 than or equal to this value.
3621 The return value from @code{fcntl} with this command is normally the value
3622 of the new file descriptor. A return value of @math{-1} indicates an
3623 error. The following @code{errno} error conditions are defined for
3628 The @var{old} argument is invalid.
3631 The @var{next-filedes} argument is invalid.
3634 There are no more file descriptors available---your program is already
3635 using the maximum. In BSD and GNU, the maximum is controlled by a
3636 resource limit that can be changed; @pxref{Limits on Resources}, for
3637 more information about the @code{RLIMIT_NOFILE} limit.
3640 @code{ENFILE} is not a possible error code for @code{dup2} because
3641 @code{dup2} does not create a new opening of a file; duplicate
3642 descriptors do not count toward the limit which @code{ENFILE}
3643 indicates. @code{EMFILE} is possible because it refers to the limit on
3644 distinct descriptor numbers in use in one process.
3647 Here is an example showing how to use @code{dup2} to do redirection.
3648 Typically, redirection of the standard streams (like @code{stdin}) is
3649 done by a shell or shell-like program before calling one of the
3650 @code{exec} functions (@pxref{Executing a File}) to execute a new
3651 program in a child process. When the new program is executed, it
3652 creates and initializes the standard streams to point to the
3653 corresponding file descriptors, before its @code{main} function is
3656 So, to redirect standard input to a file, the shell could do something
3667 file = TEMP_FAILURE_RETRY (open (filename, O_RDONLY));
3668 dup2 (file, STDIN_FILENO);
3669 TEMP_FAILURE_RETRY (close (file));
3670 execv (program, NULL);
3674 There is also a more detailed example showing how to implement redirection
3675 in the context of a pipeline of processes in @ref{Launching Jobs}.
3678 @node Descriptor Flags
3679 @section File Descriptor Flags
3680 @cindex file descriptor flags
3682 @dfn{File descriptor flags} are miscellaneous attributes of a file
3683 descriptor. These flags are associated with particular file
3684 descriptors, so that if you have created duplicate file descriptors
3685 from a single opening of a file, each descriptor has its own set of flags.
3687 Currently there is just one file descriptor flag: @code{FD_CLOEXEC},
3688 which causes the descriptor to be closed if you use any of the
3689 @code{exec@dots{}} functions (@pxref{Executing a File}).
3691 The symbols in this section are defined in the header file
3695 @deftypevr Macro int F_GETFD
3696 @standards{POSIX.1, fcntl.h}
3697 This macro is used as the @var{command} argument to @code{fcntl}, to
3698 specify that it should return the file descriptor flags associated
3699 with the @var{filedes} argument.
3701 The normal return value from @code{fcntl} with this command is a
3702 nonnegative number which can be interpreted as the bitwise OR of the
3703 individual flags (except that currently there is only one flag to use).
3705 In case of an error, @code{fcntl} returns @math{-1}. The following
3706 @code{errno} error conditions are defined for this command:
3710 The @var{filedes} argument is invalid.
3715 @deftypevr Macro int F_SETFD
3716 @standards{POSIX.1, fcntl.h}
3717 This macro is used as the @var{command} argument to @code{fcntl}, to
3718 specify that it should set the file descriptor flags associated with the
3719 @var{filedes} argument. This requires a third @code{int} argument to
3720 specify the new flags, so the form of the call is:
3723 fcntl (@var{filedes}, F_SETFD, @var{new-flags})
3726 The normal return value from @code{fcntl} with this command is an
3727 unspecified value other than @math{-1}, which indicates an error.
3728 The flags and error conditions are the same as for the @code{F_GETFD}
3732 The following macro is defined for use as a file descriptor flag with
3733 the @code{fcntl} function. The value is an integer constant usable
3734 as a bit mask value.
3736 @deftypevr Macro int FD_CLOEXEC
3737 @standards{POSIX.1, fcntl.h}
3738 @cindex close-on-exec (file descriptor flag)
3739 This flag specifies that the file descriptor should be closed when
3740 an @code{exec} function is invoked; see @ref{Executing a File}. When
3741 a file descriptor is allocated (as with @code{open} or @code{dup}),
3742 this bit is initially cleared on the new file descriptor, meaning that
3743 descriptor will survive into the new program after @code{exec}.
3746 If you want to modify the file descriptor flags, you should get the
3747 current flags with @code{F_GETFD} and modify the value. Don't assume
3748 that the flags listed here are the only ones that are implemented; your
3749 program may be run years from now and more flags may exist then. For
3750 example, here is a function to set or clear the flag @code{FD_CLOEXEC}
3751 without altering any other flags:
3754 /* @r{Set the @code{FD_CLOEXEC} flag of @var{desc} if @var{value} is nonzero,}
3755 @r{or clear the flag if @var{value} is 0.}
3756 @r{Return 0 on success, or -1 on error with @code{errno} set.} */
3759 set_cloexec_flag (int desc, int value)
3761 int oldflags = fcntl (desc, F_GETFD, 0);
3762 /* @r{If reading the flags failed, return error indication now.} */
3765 /* @r{Set just the flag we want to set.} */
3767 oldflags |= FD_CLOEXEC;
3769 oldflags &= ~FD_CLOEXEC;
3770 /* @r{Store modified flag word in the descriptor.} */
3771 return fcntl (desc, F_SETFD, oldflags);
3775 @node File Status Flags
3776 @section File Status Flags
3777 @cindex file status flags
3779 @dfn{File status flags} are used to specify attributes of the opening of a
3780 file. Unlike the file descriptor flags discussed in @ref{Descriptor
3781 Flags}, the file status flags are shared by duplicated file descriptors
3782 resulting from a single opening of the file. The file status flags are
3783 specified with the @var{flags} argument to @code{open};
3784 @pxref{Opening and Closing Files}.
3786 File status flags fall into three categories, which are described in the
3791 @ref{Access Modes}, specify what type of access is allowed to the
3792 file: reading, writing, or both. They are set by @code{open} and are
3793 returned by @code{fcntl}, but cannot be changed.
3796 @ref{Open-time Flags}, control details of what @code{open} will do.
3797 These flags are not preserved after the @code{open} call.
3800 @ref{Operating Modes}, affect how operations such as @code{read} and
3801 @code{write} are done. They are set by @code{open}, and can be fetched or
3802 changed with @code{fcntl}.
3805 The symbols in this section are defined in the header file
3810 * Access Modes:: Whether the descriptor can read or write.
3811 * Open-time Flags:: Details of @code{open}.
3812 * Operating Modes:: Special modes to control I/O operations.
3813 * Getting File Status Flags:: Fetching and changing these flags.
3817 @subsection File Access Modes
3819 The file access mode allows a file descriptor to be used for reading,
3820 writing, both, or neither. The access mode is determined when the file
3821 is opened, and never change.
3823 @deftypevr Macro int O_RDONLY
3824 @standards{POSIX.1, fcntl.h}
3825 Open the file for read access.
3828 @deftypevr Macro int O_WRONLY
3829 @standards{POSIX.1, fcntl.h}
3830 Open the file for write access.
3833 @deftypevr Macro int O_RDWR
3834 @standards{POSIX.1, fcntl.h}
3835 Open the file for both reading and writing.
3838 @deftypevr Macro int O_PATH
3839 @standards{Linux, fcntl.h}
3840 Obtain a file descriptor for the file, but do not open the file for
3841 reading or writing. Permission checks for the file itself are skipped
3842 when the file is opened (but permission to access the directory that
3843 contains it is still needed), and permissions are checked when the
3844 descriptor is used later on.
3846 For example, such descriptors can be used with the @code{fexecve}
3847 function (@pxref{Executing a File}). Other applications involve the
3848 @samp{*at} function variants, along with the @code{AT_EMPTY_PATH} flag.
3849 @xref{Descriptor-Relative Access}.
3851 This access mode is specific to Linux. On @gnuhurdsystems{}, it is
3852 possible to use @code{O_EXEC} explicitly, or specify no access modes
3856 The portable file access modes @code{O_RDONLY}, @code{O_WRONLY}, and
3857 @code{O_RDWR} may not correspond to individual bits. To determine the
3858 file access mode with @code{fcntl}, you must extract the access mode
3859 bits from the retrieved file status flags, using the @code{O_ACCMODE}
3862 @deftypevr Macro int O_ACCMODE
3863 @standards{POSIX.1, fcntl.h}
3865 This macro is a mask that can be bitwise-ANDed with the file status flag
3866 value to recover the file access mode, assuming that a standard file
3867 access mode is in use.
3870 If a non-standard file access mode is used (such as @code{O_PATH} or
3871 @code{O_EXEC}), masking with @code{O_ACCMODE} may give incorrect
3872 results. These non-standard access modes are identified by individual
3873 bits and have to be checked directly (without masking with
3874 @code{O_ACCMODE} first).
3876 On @gnuhurdsystems{} (but not on other systems), @code{O_RDONLY} and
3877 @code{O_WRONLY} are independent bits that can be bitwise-ORed together,
3878 and it is valid for either bit to be set or clear. This means that
3879 @code{O_RDWR} is the same as @code{O_RDONLY|O_WRONLY}. A file access
3880 mode of zero is permissible; it allows no operations that do input or
3881 output to the file, but does allow other operations such as
3882 @code{fchmod}. On @gnuhurdsystems{}, since ``read-only'' or ``write-only''
3883 is a misnomer, @file{fcntl.h} defines additional names for the file
3886 @deftypevr Macro int O_READ
3887 @standards{GNU, fcntl.h (optional)}
3888 Open the file for reading. Same as @code{O_RDONLY}; only defined on GNU/Hurd.
3891 @deftypevr Macro int O_WRITE
3892 @standards{GNU, fcntl.h (optional)}
3893 Open the file for writing. Same as @code{O_WRONLY}; only defined on GNU/Hurd.
3896 @deftypevr Macro int O_EXEC
3897 @standards{GNU, fcntl.h (optional)}
3898 Open the file for executing. Only defined on GNU/Hurd.
3901 @node Open-time Flags
3902 @subsection Open-time Flags
3904 The open-time flags specify options affecting how @code{open} will behave.
3905 These options are not preserved once the file is open. The exception to
3906 this is @code{O_NONBLOCK}, which is also an I/O operating mode and so it
3907 @emph{is} saved. @xref{Opening and Closing Files}, for how to call
3910 There are two sorts of options specified by open-time flags.
3914 @dfn{File name translation flags} affect how @code{open} looks up the
3915 file name to locate the file, and whether the file can be created.
3916 @cindex file name translation flags
3917 @cindex flags, file name translation
3920 @dfn{Open-time action flags} specify extra operations that @code{open} will
3921 perform on the file once it is open.
3922 @cindex open-time action flags
3923 @cindex flags, open-time action
3926 Here are the file name translation flags.
3928 @deftypevr Macro int O_CREAT
3929 @standards{POSIX.1, fcntl.h}
3930 If set, the file will be created if it doesn't already exist.
3931 @c !!! mode arg, umask
3932 @cindex create on open (file status flag)
3935 @deftypevr Macro int O_EXCL
3936 @standards{POSIX.1, fcntl.h}
3937 If both @code{O_CREAT} and @code{O_EXCL} are set, then @code{open} fails
3938 if the specified file already exists. This is guaranteed to never
3939 clobber an existing file.
3941 The @code{O_EXCL} flag has a special meaning in combination with
3942 @code{O_TMPFILE}; see below.
3945 @deftypevr Macro int O_DIRECTORY
3946 @standards{POSIX.1, fcntl.h}
3947 If set, the open operation fails if the given name is not the name of
3948 a directory. The @code{errno} variable is set to @code{ENOTDIR} for
3949 this error condition.
3952 @deftypevr Macro int O_NOFOLLOW
3953 @standards{POSIX.1, fcntl.h}
3954 If set, the open operation fails if the final component of the file name
3955 refers to a symbolic link. The @code{errno} variable is set to
3956 @code{ELOOP} for this error condition.
3959 @deftypevr Macro int O_TMPFILE
3960 @standards{GNU, fcntl.h}
3961 If this flag is specified, functions in the @code{open} family create an
3962 unnamed temporary file. In this case, the pathname argument to the
3963 @code{open} family of functions (@pxref{Opening and Closing Files}) is
3964 interpreted as the directory in which the temporary file is created
3965 (thus determining the file system which provides the storage for the
3966 file). The @code{O_TMPFILE} flag must be combined with @code{O_WRONLY}
3967 or @code{O_RDWR}, and the @var{mode} argument is required.
3969 The temporary file can later be given a name using @code{linkat},
3970 turning it into a regular file. This allows the atomic creation of a
3971 file with the specific file attributes (mode and extended attributes)
3972 and file contents. If, for security reasons, it is not desirable that a
3973 name can be given to the file, the @code{O_EXCL} flag can be specified
3974 along with @code{O_TMPFILE}.
3976 Not all kernels support this open flag. If this flag is unsupported, an
3977 attempt to create an unnamed temporary file fails with an error of
3978 @code{EINVAL}. If the underlying file system does not support the
3979 @code{O_TMPFILE} flag, an @code{EOPNOTSUPP} error is the result.
3981 The @code{O_TMPFILE} flag is a GNU extension.
3984 @deftypevr Macro int O_NONBLOCK
3985 @standards{POSIX.1, fcntl.h}
3986 @cindex non-blocking open
3987 This prevents @code{open} from blocking for a ``long time'' to open the
3988 file. This is only meaningful for some kinds of files, usually devices
3989 such as serial ports; when it is not meaningful, it is harmless and
3990 ignored. Often, opening a port to a modem blocks until the modem reports
3991 carrier detection; if @code{O_NONBLOCK} is specified, @code{open} will
3992 return immediately without a carrier.
3994 Note that the @code{O_NONBLOCK} flag is overloaded as both an I/O operating
3995 mode and a file name translation flag. This means that specifying
3996 @code{O_NONBLOCK} in @code{open} also sets nonblocking I/O mode;
3997 @pxref{Operating Modes}. To open the file without blocking but do normal
3998 I/O that blocks, you must call @code{open} with @code{O_NONBLOCK} set and
3999 then call @code{fcntl} to turn the bit off.
4002 @deftypevr Macro int O_NOCTTY
4003 @standards{POSIX.1, fcntl.h}
4004 If the named file is a terminal device, don't make it the controlling
4005 terminal for the process. @xref{Job Control}, for information about
4006 what it means to be the controlling terminal.
4008 On @gnuhurdsystems{} and 4.4 BSD, opening a file never makes it the
4009 controlling terminal and @code{O_NOCTTY} is zero. However, @gnulinuxsystems{}
4010 and some other systems use a nonzero value for @code{O_NOCTTY} and set the
4011 controlling terminal when you open a file that is a terminal device; so
4012 to be portable, use @code{O_NOCTTY} when it is important to avoid this.
4013 @cindex controlling terminal, setting
4016 The following three file name translation flags exist only on
4019 @deftypevr Macro int O_IGNORE_CTTY
4020 @standards{GNU, fcntl.h (optional)}
4021 Do not recognize the named file as the controlling terminal, even if it
4022 refers to the process's existing controlling terminal device. Operations
4023 on the new file descriptor will never induce job control signals.
4027 @deftypevr Macro int O_NOLINK
4028 @standards{GNU, fcntl.h (optional)}
4029 If the named file is a symbolic link, open the link itself instead of
4030 the file it refers to. (@code{fstat} on the new file descriptor will
4031 return the information returned by @code{lstat} on the link's name.)
4032 @cindex symbolic link, opening
4035 @deftypevr Macro int O_NOTRANS
4036 @standards{GNU, fcntl.h (optional)}
4037 If the named file is specially translated, do not invoke the translator.
4038 Open the bare file the translator itself sees.
4042 The open-time action flags tell @code{open} to do additional operations
4043 which are not really related to opening the file. The reason to do them
4044 as part of @code{open} instead of in separate calls is that @code{open}
4045 can do them @i{atomically}.
4047 @deftypevr Macro int O_TRUNC
4048 @standards{POSIX.1, fcntl.h}
4049 Truncate the file to zero length. This option is only useful for
4050 regular files, not special files such as directories or FIFOs. POSIX.1
4051 requires that you open the file for writing to use @code{O_TRUNC}. In
4052 BSD and GNU you must have permission to write the file to truncate it,
4053 but you need not open for write access.
4055 This is the only open-time action flag specified by POSIX.1. There is
4056 no good reason for truncation to be done by @code{open}, instead of by
4057 calling @code{ftruncate} afterwards. The @code{O_TRUNC} flag existed in
4058 Unix before @code{ftruncate} was invented, and is retained for backward
4062 The remaining operating modes are BSD extensions. They exist only
4063 on some systems. On other systems, these macros are not defined.
4065 @deftypevr Macro int O_SHLOCK
4066 @standards{BSD, fcntl.h (optional)}
4067 Acquire a shared lock on the file, as with @code{flock}.
4070 If @code{O_CREAT} is specified, the locking is done atomically when
4071 creating the file. You are guaranteed that no other process will get
4072 the lock on the new file first.
4075 @deftypevr Macro int O_EXLOCK
4076 @standards{BSD, fcntl.h (optional)}
4077 Acquire an exclusive lock on the file, as with @code{flock}.
4078 @xref{File Locks}. This is atomic like @code{O_SHLOCK}.
4081 @node Operating Modes
4082 @subsection I/O Operating Modes
4084 The operating modes affect how input and output operations using a file
4085 descriptor work. These flags are set by @code{open} and can be fetched
4086 and changed with @code{fcntl}.
4088 @deftypevr Macro int O_APPEND
4089 @standards{POSIX.1, fcntl.h}
4090 The bit that enables append mode for the file. If set, then all
4091 @code{write} operations write the data at the end of the file, extending
4092 it, regardless of the current file position. This is the only reliable
4093 way to append to a file. In append mode, you are guaranteed that the
4094 data you write will always go to the current end of the file, regardless
4095 of other processes writing to the file. Conversely, if you simply set
4096 the file position to the end of file and write, then another process can
4097 extend the file after you set the file position but before you write,
4098 resulting in your data appearing someplace before the real end of file.
4101 @deftypevr Macro int O_NONBLOCK
4102 @standards{POSIX.1, fcntl.h}
4103 The bit that enables nonblocking mode for the file. If this bit is set,
4104 @code{read} requests on the file can return immediately with a failure
4105 status if there is no input immediately available, instead of blocking.
4106 Likewise, @code{write} requests can also return immediately with a
4107 failure status if the output can't be written immediately.
4109 Note that the @code{O_NONBLOCK} flag is overloaded as both an I/O
4110 operating mode and a file name translation flag; @pxref{Open-time Flags}.
4113 @deftypevr Macro int O_NDELAY
4114 @standards{BSD, fcntl.h}
4115 This is an obsolete name for @code{O_NONBLOCK}, provided for
4116 compatibility with BSD. It is not defined by the POSIX.1 standard.
4119 The remaining operating modes are BSD and GNU extensions. They exist only
4120 on some systems. On other systems, these macros are not defined.
4122 @deftypevr Macro int O_ASYNC
4123 @standards{BSD, fcntl.h}
4124 The bit that enables asynchronous input mode. If set, then @code{SIGIO}
4125 signals will be generated when input is available. @xref{Interrupt Input}.
4127 Asynchronous input mode is a BSD feature.
4130 @deftypevr Macro int O_FSYNC
4131 @standards{BSD, fcntl.h}
4132 The bit that enables synchronous writing for the file. If set, each
4133 @code{write} call will make sure the data is reliably stored on disk before
4134 returning. @c !!! xref fsync
4136 Synchronous writing is a BSD feature.
4139 @deftypevr Macro int O_SYNC
4140 @standards{BSD, fcntl.h}
4141 This is another name for @code{O_FSYNC}. They have the same value.
4144 @deftypevr Macro int O_NOATIME
4145 @standards{GNU, fcntl.h}
4146 If this bit is set, @code{read} will not update the access time of the
4147 file. @xref{File Times}. This is used by programs that do backups, so
4148 that backing a file up does not count as reading it.
4149 Only the owner of the file or the superuser may use this bit.
4151 This is a GNU extension.
4154 @node Getting File Status Flags
4155 @subsection Getting and Setting File Status Flags
4157 The @code{fcntl} function can fetch or change file status flags.
4159 @deftypevr Macro int F_GETFL
4160 @standards{POSIX.1, fcntl.h}
4161 This macro is used as the @var{command} argument to @code{fcntl}, to
4162 read the file status flags for the open file with descriptor
4165 The normal return value from @code{fcntl} with this command is a
4166 nonnegative number which can be interpreted as the bitwise OR of the
4167 individual flags. Since the file access modes are not single-bit values,
4168 you can mask off other bits in the returned flags with @code{O_ACCMODE}
4171 In case of an error, @code{fcntl} returns @math{-1}. The following
4172 @code{errno} error conditions are defined for this command:
4176 The @var{filedes} argument is invalid.
4180 @deftypevr Macro int F_SETFL
4181 @standards{POSIX.1, fcntl.h}
4182 This macro is used as the @var{command} argument to @code{fcntl}, to set
4183 the file status flags for the open file corresponding to the
4184 @var{filedes} argument. This command requires a third @code{int}
4185 argument to specify the new flags, so the call looks like this:
4188 fcntl (@var{filedes}, F_SETFL, @var{new-flags})
4191 You can't change the access mode for the file in this way; that is,
4192 whether the file descriptor was opened for reading or writing.
4194 The normal return value from @code{fcntl} with this command is an
4195 unspecified value other than @math{-1}, which indicates an error. The
4196 error conditions are the same as for the @code{F_GETFL} command.
4199 If you want to modify the file status flags, you should get the current
4200 flags with @code{F_GETFL} and modify the value. Don't assume that the
4201 flags listed here are the only ones that are implemented; your program
4202 may be run years from now and more flags may exist then. For example,
4203 here is a function to set or clear the flag @code{O_NONBLOCK} without
4204 altering any other flags:
4208 /* @r{Set the @code{O_NONBLOCK} flag of @var{desc} if @var{value} is nonzero,}
4209 @r{or clear the flag if @var{value} is 0.}
4210 @r{Return 0 on success, or -1 on error with @code{errno} set.} */
4213 set_nonblock_flag (int desc, int value)
4215 int oldflags = fcntl (desc, F_GETFL, 0);
4216 /* @r{If reading the flags failed, return error indication now.} */
4219 /* @r{Set just the flag we want to set.} */
4221 oldflags |= O_NONBLOCK;
4223 oldflags &= ~O_NONBLOCK;
4224 /* @r{Store modified flag word in the descriptor.} */
4225 return fcntl (desc, F_SETFL, oldflags);
4234 @cindex record locking
4235 This section describes record locks that are associated with the process.
4236 There is also a different type of record lock that is associated with the
4237 open file description instead of the process. @xref{Open File Description Locks}.
4239 The remaining @code{fcntl} commands are used to support @dfn{record
4240 locking}, which permits multiple cooperating programs to prevent each
4241 other from simultaneously accessing parts of a file in error-prone
4244 @cindex exclusive lock
4246 An @dfn{exclusive} or @dfn{write} lock gives a process exclusive access
4247 for writing to the specified part of the file. While a write lock is in
4248 place, no other process can lock that part of the file.
4252 A @dfn{shared} or @dfn{read} lock prohibits any other process from
4253 requesting a write lock on the specified part of the file. However,
4254 other processes can request read locks.
4256 The @code{read} and @code{write} functions do not actually check to see
4257 whether there are any locks in place. If you want to implement a
4258 locking protocol for a file shared by multiple processes, your application
4259 must do explicit @code{fcntl} calls to request and clear locks at the
4262 Locks are associated with processes. A process can only have one kind
4263 of lock set for each byte of a given file. When any file descriptor for
4264 that file is closed by the process, all of the locks that process holds
4265 on that file are released, even if the locks were made using other
4266 descriptors that remain open. Likewise, locks are released when a
4267 process exits, and are not inherited by child processes created using
4268 @code{fork} (@pxref{Creating a Process}).
4270 When making a lock, use a @code{struct flock} to specify what kind of
4271 lock and where. This data type and the associated macros for the
4272 @code{fcntl} function are declared in the header file @file{fcntl.h}.
4275 @deftp {Data Type} {struct flock}
4276 @standards{POSIX.1, fcntl.h}
4277 This structure is used with the @code{fcntl} function to describe a file
4278 lock. It has these members:
4281 @item short int l_type
4282 Specifies the type of the lock; one of @code{F_RDLCK}, @code{F_WRLCK}, or
4285 @item short int l_whence
4286 This corresponds to the @var{whence} argument to @code{fseek} or
4287 @code{lseek}, and specifies what the offset is relative to. Its value
4288 can be one of @code{SEEK_SET}, @code{SEEK_CUR}, or @code{SEEK_END}.
4291 This specifies the offset of the start of the region to which the lock
4292 applies, and is given in bytes relative to the point specified by the
4293 @code{l_whence} member.
4296 This specifies the length of the region to be locked. A value of
4297 @code{0} is treated specially; it means the region extends to the end of
4301 This field is the process ID (@pxref{Process Creation Concepts}) of the
4302 process holding the lock. It is filled in by calling @code{fcntl} with
4303 the @code{F_GETLK} command, but is ignored when making a lock. If the
4304 conflicting lock is an open file description lock
4305 (@pxref{Open File Description Locks}), then this field will be set to
4310 @deftypevr Macro int F_GETLK
4311 @standards{POSIX.1, fcntl.h}
4312 This macro is used as the @var{command} argument to @code{fcntl}, to
4313 specify that it should get information about a lock. This command
4314 requires a third argument of type @w{@code{struct flock *}} to be passed
4315 to @code{fcntl}, so that the form of the call is:
4318 fcntl (@var{filedes}, F_GETLK, @var{lockp})
4321 If there is a lock already in place that would block the lock described
4322 by the @var{lockp} argument, information about that lock overwrites
4323 @code{*@var{lockp}}. Existing locks are not reported if they are
4324 compatible with making a new lock as specified. Thus, you should
4325 specify a lock type of @code{F_WRLCK} if you want to find out about both
4326 read and write locks, or @code{F_RDLCK} if you want to find out about
4329 There might be more than one lock affecting the region specified by the
4330 @var{lockp} argument, but @code{fcntl} only returns information about
4331 one of them. The @code{l_whence} member of the @var{lockp} structure is
4332 set to @code{SEEK_SET} and the @code{l_start} and @code{l_len} fields
4333 set to identify the locked region.
4335 If no lock applies, the only change to the @var{lockp} structure is to
4336 update the @code{l_type} to a value of @code{F_UNLCK}.
4338 The normal return value from @code{fcntl} with this command is an
4339 unspecified value other than @math{-1}, which is reserved to indicate an
4340 error. The following @code{errno} error conditions are defined for
4345 The @var{filedes} argument is invalid.
4348 Either the @var{lockp} argument doesn't specify valid lock information,
4349 or the file associated with @var{filedes} doesn't support locks.
4353 @deftypevr Macro int F_SETLK
4354 @standards{POSIX.1, fcntl.h}
4355 This macro is used as the @var{command} argument to @code{fcntl}, to
4356 specify that it should set or clear a lock. This command requires a
4357 third argument of type @w{@code{struct flock *}} to be passed to
4358 @code{fcntl}, so that the form of the call is:
4361 fcntl (@var{filedes}, F_SETLK, @var{lockp})
4364 If the process already has a lock on any part of the region, the old lock
4365 on that part is replaced with the new lock. You can remove a lock
4366 by specifying a lock type of @code{F_UNLCK}.
4368 If the lock cannot be set, @code{fcntl} returns immediately with a value
4369 of @math{-1}. This function does not block while waiting for other processes
4370 to release locks. If @code{fcntl} succeeds, it returns a value other
4373 The following @code{errno} error conditions are defined for this
4379 The lock cannot be set because it is blocked by an existing lock on the
4380 file. Some systems use @code{EAGAIN} in this case, and other systems
4381 use @code{EACCES}; your program should treat them alike, after
4382 @code{F_SETLK}. (@gnulinuxhurdsystems{} always use @code{EAGAIN}.)
4385 Either: the @var{filedes} argument is invalid; you requested a read lock
4386 but the @var{filedes} is not open for read access; or, you requested a
4387 write lock but the @var{filedes} is not open for write access.
4390 Either the @var{lockp} argument doesn't specify valid lock information,
4391 or the file associated with @var{filedes} doesn't support locks.
4394 The system has run out of file lock resources; there are already too
4395 many file locks in place.
4397 Well-designed file systems never report this error, because they have no
4398 limitation on the number of locks. However, you must still take account
4399 of the possibility of this error, as it could result from network access
4400 to a file system on another machine.
4404 @deftypevr Macro int F_SETLKW
4405 @standards{POSIX.1, fcntl.h}
4406 This macro is used as the @var{command} argument to @code{fcntl}, to
4407 specify that it should set or clear a lock. It is just like the
4408 @code{F_SETLK} command, but causes the process to block (or wait)
4409 until the request can be specified.
4411 This command requires a third argument of type @code{struct flock *}, as
4412 for the @code{F_SETLK} command.
4414 The @code{fcntl} return values and errors are the same as for the
4415 @code{F_SETLK} command, but these additional @code{errno} error conditions
4416 are defined for this command:
4420 The function was interrupted by a signal while it was waiting.
4421 @xref{Interrupted Primitives}.
4424 The specified region is being locked by another process. But that
4425 process is waiting to lock a region which the current process has
4426 locked, so waiting for the lock would result in deadlock. The system
4427 does not guarantee that it will detect all such conditions, but it lets
4428 you know if it notices one.
4433 The following macros are defined for use as values for the @code{l_type}
4434 member of the @code{flock} structure. The values are integer constants.
4438 @standards{POSIX.1, fcntl.h}
4439 This macro is used to specify a read (or shared) lock.
4442 @standards{POSIX.1, fcntl.h}
4443 This macro is used to specify a write (or exclusive) lock.
4446 @standards{POSIX.1, fcntl.h}
4447 This macro is used to specify that the region is unlocked.
4450 As an example of a situation where file locking is useful, consider a
4451 program that can be run simultaneously by several different users, that
4452 logs status information to a common file. One example of such a program
4453 might be a game that uses a file to keep track of high scores. Another
4454 example might be a program that records usage or accounting information
4455 for billing purposes.
4457 Having multiple copies of the program simultaneously writing to the
4458 file could cause the contents of the file to become mixed up. But
4459 you can prevent this kind of problem by setting a write lock on the
4460 file before actually writing to the file.
4462 If the program also needs to read the file and wants to make sure that
4463 the contents of the file are in a consistent state, then it can also use
4464 a read lock. While the read lock is set, no other process can lock
4465 that part of the file for writing.
4467 @c ??? This section could use an example program.
4469 Remember that file locks are only an @emph{advisory} protocol for
4470 controlling access to a file. There is still potential for access to
4471 the file by programs that don't use the lock protocol.
4473 @node Open File Description Locks
4474 @section Open File Description Locks
4476 In contrast to process-associated record locks (@pxref{File Locks}),
4477 open file description record locks are associated with an open file
4478 description rather than a process.
4480 Using @code{fcntl} to apply an open file description lock on a region that
4481 already has an existing open file description lock that was created via the
4482 same file descriptor will never cause a lock conflict.
4484 Open file description locks are also inherited by child processes across
4485 @code{fork}, or @code{clone} with @code{CLONE_FILES} set
4486 (@pxref{Creating a Process}), along with the file descriptor.
4488 It is important to distinguish between the open file @emph{description} (an
4489 instance of an open file, usually created by a call to @code{open}) and
4490 an open file @emph{descriptor}, which is a numeric value that refers to the
4491 open file description. The locks described here are associated with the
4492 open file @emph{description} and not the open file @emph{descriptor}.
4494 Using @code{dup} (@pxref{Duplicating Descriptors}) to copy a file
4495 descriptor does not give you a new open file description, but rather copies a
4496 reference to an existing open file description and assigns it to a new
4497 file descriptor. Thus, open file description locks set on a file
4498 descriptor cloned by @code{dup} will never conflict with open file
4499 description locks set on the original descriptor since they refer to the
4500 same open file description. Depending on the range and type of lock
4501 involved, the original lock may be modified by a @code{F_OFD_SETLK} or
4502 @code{F_OFD_SETLKW} command in this situation however.
4504 Open file description locks always conflict with process-associated locks,
4505 even if acquired by the same process or on the same open file
4508 Open file description locks use the same @code{struct flock} as
4509 process-associated locks as an argument (@pxref{File Locks}) and the
4510 macros for the @code{command} values are also declared in the header file
4511 @file{fcntl.h}. To use them, the macro @code{_GNU_SOURCE} must be
4512 defined prior to including any header file.
4514 In contrast to process-associated locks, any @code{struct flock} used as
4515 an argument to open file description lock commands must have the @code{l_pid}
4516 value set to @math{0}. Also, when returning information about an
4517 open file description lock in a @code{F_GETLK} or @code{F_OFD_GETLK} request,
4518 the @code{l_pid} field in @code{struct flock} will be set to @math{-1}
4519 to indicate that the lock is not associated with a process.
4521 When the same @code{struct flock} is reused as an argument to a
4522 @code{F_OFD_SETLK} or @code{F_OFD_SETLKW} request after being used for an
4523 @code{F_OFD_GETLK} request, it is necessary to inspect and reset the
4524 @code{l_pid} field to @math{0}.
4528 @deftypevr Macro int F_OFD_GETLK
4529 This macro is used as the @var{command} argument to @code{fcntl}, to
4530 specify that it should get information about a lock. This command
4531 requires a third argument of type @w{@code{struct flock *}} to be passed
4532 to @code{fcntl}, so that the form of the call is:
4535 fcntl (@var{filedes}, F_OFD_GETLK, @var{lockp})
4538 If there is a lock already in place that would block the lock described
4539 by the @var{lockp} argument, information about that lock is written to
4540 @code{*@var{lockp}}. Existing locks are not reported if they are
4541 compatible with making a new lock as specified. Thus, you should
4542 specify a lock type of @code{F_WRLCK} if you want to find out about both
4543 read and write locks, or @code{F_RDLCK} if you want to find out about
4546 There might be more than one lock affecting the region specified by the
4547 @var{lockp} argument, but @code{fcntl} only returns information about
4548 one of them. Which lock is returned in this situation is undefined.
4550 The @code{l_whence} member of the @var{lockp} structure are set to
4551 @code{SEEK_SET} and the @code{l_start} and @code{l_len} fields are set
4552 to identify the locked region.
4554 If no conflicting lock exists, the only change to the @var{lockp} structure
4555 is to update the @code{l_type} field to the value @code{F_UNLCK}.
4557 The normal return value from @code{fcntl} with this command is either @math{0}
4558 on success or @math{-1}, which indicates an error. The following @code{errno}
4559 error conditions are defined for this command:
4563 The @var{filedes} argument is invalid.
4566 Either the @var{lockp} argument doesn't specify valid lock information,
4567 the operating system kernel doesn't support open file description locks, or the file
4568 associated with @var{filedes} doesn't support locks.
4572 @deftypevr Macro int F_OFD_SETLK
4573 @standards{POSIX.1, fcntl.h}
4574 This macro is used as the @var{command} argument to @code{fcntl}, to
4575 specify that it should set or clear a lock. This command requires a
4576 third argument of type @w{@code{struct flock *}} to be passed to
4577 @code{fcntl}, so that the form of the call is:
4580 fcntl (@var{filedes}, F_OFD_SETLK, @var{lockp})
4583 If the open file already has a lock on any part of the
4584 region, the old lock on that part is replaced with the new lock. You
4585 can remove a lock by specifying a lock type of @code{F_UNLCK}.
4587 If the lock cannot be set, @code{fcntl} returns immediately with a value
4588 of @math{-1}. This command does not wait for other tasks
4589 to release locks. If @code{fcntl} succeeds, it returns @math{0}.
4591 The following @code{errno} error conditions are defined for this
4596 The lock cannot be set because it is blocked by an existing lock on the
4600 Either: the @var{filedes} argument is invalid; you requested a read lock
4601 but the @var{filedes} is not open for read access; or, you requested a
4602 write lock but the @var{filedes} is not open for write access.
4605 Either the @var{lockp} argument doesn't specify valid lock information,
4606 the operating system kernel doesn't support open file description locks, or the
4607 file associated with @var{filedes} doesn't support locks.
4610 The system has run out of file lock resources; there are already too
4611 many file locks in place.
4613 Well-designed file systems never report this error, because they have no
4614 limitation on the number of locks. However, you must still take account
4615 of the possibility of this error, as it could result from network access
4616 to a file system on another machine.
4620 @deftypevr Macro int F_OFD_SETLKW
4621 @standards{POSIX.1, fcntl.h}
4622 This macro is used as the @var{command} argument to @code{fcntl}, to
4623 specify that it should set or clear a lock. It is just like the
4624 @code{F_OFD_SETLK} command, but causes the process to wait until the request
4627 This command requires a third argument of type @code{struct flock *}, as
4628 for the @code{F_OFD_SETLK} command.
4630 The @code{fcntl} return values and errors are the same as for the
4631 @code{F_OFD_SETLK} command, but these additional @code{errno} error conditions
4632 are defined for this command:
4636 The function was interrupted by a signal while it was waiting.
4637 @xref{Interrupted Primitives}.
4642 Open file description locks are useful in the same sorts of situations as
4643 process-associated locks. They can also be used to synchronize file
4644 access between threads within the same process by having each thread perform
4645 its own @code{open} of the file, to obtain its own open file description.
4647 Because open file description locks are automatically freed only upon
4648 closing the last file descriptor that refers to the open file
4649 description, this locking mechanism avoids the possibility that locks
4650 are inadvertently released due to a library routine opening and closing
4651 a file without the application being aware.
4653 As with process-associated locks, open file description locks are advisory.
4655 @node Open File Description Locks Example
4656 @section Open File Description Locks Example
4658 Here is an example of using open file description locks in a threaded
4659 program. If this program used process-associated locks, then it would be
4660 subject to data corruption because process-associated locks are shared
4661 by the threads inside a process, and thus cannot be used by one thread
4662 to lock out another thread in the same process.
4664 Proper error handling has been omitted in the following program for
4668 @include ofdlocks.c.texi
4671 This example creates three threads each of which loops five times,
4672 appending to the file. Access to the file is serialized via open file
4673 description locks. If we compile and run the above program, we'll end up
4674 with /tmp/foo that has 15 lines in it.
4676 If we, however, were to replace the @code{F_OFD_SETLK} and
4677 @code{F_OFD_SETLKW} commands with their process-associated lock
4678 equivalents, the locking essentially becomes a noop since it is all done
4679 within the context of the same process. That leads to data corruption
4680 (typically manifested as missing lines) as some threads race in and
4681 overwrite the data written by others.
4683 @node Interrupt Input
4684 @section Interrupt-Driven Input
4686 @cindex interrupt-driven input
4687 If you set the @code{O_ASYNC} status flag on a file descriptor
4688 (@pxref{File Status Flags}), a @code{SIGIO} signal is sent whenever
4689 input or output becomes possible on that file descriptor. The process
4690 or process group to receive the signal can be selected by using the
4691 @code{F_SETOWN} command to the @code{fcntl} function. If the file
4692 descriptor is a socket, this also selects the recipient of @code{SIGURG}
4693 signals that are delivered when out-of-band data arrives on that socket;
4694 see @ref{Out-of-Band Data}. (@code{SIGURG} is sent in any situation
4695 where @code{select} would report the socket as having an ``exceptional
4696 condition''. @xref{Waiting for I/O}.)
4698 If the file descriptor corresponds to a terminal device, then @code{SIGIO}
4699 signals are sent to the foreground process group of the terminal.
4703 The symbols in this section are defined in the header file
4706 @deftypevr Macro int F_GETOWN
4707 @standards{BSD, fcntl.h}
4708 This macro is used as the @var{command} argument to @code{fcntl}, to
4709 specify that it should get information about the process or process
4710 group to which @code{SIGIO} signals are sent. (For a terminal, this is
4711 actually the foreground process group ID, which you can get using
4712 @code{tcgetpgrp}; see @ref{Terminal Access Functions}.)
4714 The return value is interpreted as a process ID; if negative, its
4715 absolute value is the process group ID.
4717 The following @code{errno} error condition is defined for this command:
4721 The @var{filedes} argument is invalid.
4725 @deftypevr Macro int F_SETOWN
4726 @standards{BSD, fcntl.h}
4727 This macro is used as the @var{command} argument to @code{fcntl}, to
4728 specify that it should set the process or process group to which
4729 @code{SIGIO} signals are sent. This command requires a third argument
4730 of type @code{pid_t} to be passed to @code{fcntl}, so that the form of
4734 fcntl (@var{filedes}, F_SETOWN, @var{pid})
4737 The @var{pid} argument should be a process ID. You can also pass a
4738 negative number whose absolute value is a process group ID.
4740 The return value from @code{fcntl} with this command is @math{-1}
4741 in case of error and some other value if successful. The following
4742 @code{errno} error conditions are defined for this command:
4746 The @var{filedes} argument is invalid.
4749 There is no process or process group corresponding to @var{pid}.
4753 @c ??? This section could use an example program.
4756 @section Generic I/O Control operations
4757 @cindex generic i/o control operations
4760 @gnusystems{} can handle most input/output operations on many different
4761 devices and objects in terms of a few file primitives - @code{read},
4762 @code{write} and @code{lseek}. However, most devices also have a few
4763 peculiar operations which do not fit into this model. Such as:
4768 Changing the character font used on a terminal.
4771 Telling a magnetic tape system to rewind or fast forward. (Since they
4772 cannot move in byte increments, @code{lseek} is inapplicable).
4775 Ejecting a disk from a drive.
4778 Playing an audio track from a CD-ROM drive.
4781 Maintaining routing tables for a network.
4785 Although some such objects such as sockets and terminals
4786 @footnote{Actually, the terminal-specific functions are implemented with
4787 IOCTLs on many platforms.} have special functions of their own, it would
4788 not be practical to create functions for all these cases.
4790 Instead these minor operations, known as @dfn{IOCTL}s, are assigned code
4791 numbers and multiplexed through the @code{ioctl} function, defined in
4792 @code{sys/ioctl.h}. The code numbers themselves are defined in many
4795 @deftypefun int ioctl (int @var{filedes}, int @var{command}, @dots{})
4796 @standards{BSD, sys/ioctl.h}
4797 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
4799 The @code{ioctl} function performs the generic I/O operation
4800 @var{command} on @var{filedes}.
4802 A third argument is usually present, either a single number or a pointer
4803 to a structure. The meaning of this argument, the returned value, and
4804 any error codes depends upon the command used. Often @math{-1} is
4805 returned for a failure.
4809 On some systems, IOCTLs used by different devices share the same numbers.
4810 Thus, although use of an inappropriate IOCTL @emph{usually} only produces
4811 an error, you should not attempt to use device-specific IOCTLs on an
4814 Most IOCTLs are OS-specific and/or only used in special system utilities,
4815 and are thus beyond the scope of this document. For an example of the use
4816 of an IOCTL, see @ref{Out-of-Band Data}.
4818 @node Other Low-Level I/O APIs
4819 @section Other low-level-I/O-related functions
4821 @deftp {Data Type} {struct pollfd}
4822 @standards{POSIX.1,poll.h}
4825 @deftp {Data Type} {struct epoll_event}
4826 @standards{Linux,sys/epoll.h}
4829 @deftypefun int poll (struct pollfd *@var{fds}, nfds_t @var{nfds}, int @var{timeout})
4831 @manpagefunctionstub{poll,2}
4834 @deftypefun int epoll_create(int @var{size})
4836 @manpagefunctionstub{epoll_create,2}
4839 @deftypefun int epoll_wait(int @var{epfd}, struct epoll_event *@var{events}, int @var{maxevents}, int @var{timeout})
4841 @manpagefunctionstub{epoll_wait,2}