---
name: "io_trywrite"
section: "3diet"
platform: "linux"
package: "libowfat-dev"
version: "0.28-2"
release: "Debian 6.0 (Squeeze)"
platforms: ["linux"]
url: "https://new.carta.tech/io_trywrite/3diet"
---

# io\_trywrite(3diet)

write to a descriptor without blocking

## NAME

io\_trywrite - write to a descriptor without blocking

## SYNTAX

**#include \<io.h\>**

int **io\_trywrite**(int64 fd,const char\* buf,int64 len);

## DESCRIPTION

io\_trywrite tries to write *len* bytes of data from buf\[0\], buf\[1\], ..., buf\[len-1\] to descriptor *fd*. (The effects are undefined if *len* is 0 or smaller.) There are several possible results:

- •

  o\_trywrite returns an integer between 1 and *len*: This number of bytes was immediately written from the beginning of *buf*. Note that this number can be, and often is, smaller than *len*; you must not assume that io\_trywrite always succeeds in writing exactly *len* bytes.

- •

  io\_trywrite returns -1, setting *errno* to EAGAIN: No bytes were written, because the descriptor is not ready. For example, the descriptor is writing to a full pipe that could still be read.

- •

  io\_trywrite returns -3, setting *errno* to something other than EAGAIN: No bytes were written, because the write attempt encountered a persistent error, such as a serious disk failure (EIO), an unreachable network (ENETUNREACH), or an invalid descriptor number (EBADF).

io\_trywrite does not pause waiting for a descriptor that is not ready. If you want to pause, use io\_waitread or io\_wait.

You can make io\_trywrite faster and more efficient by making the socket non-blocking with io\_nonblock().

Once upon a time, many UNIX programs neglected to check the success of their writes. They would often encounter EPIPE, and would blithely continue writing, rather than exiting with an appropriate exit code. The UNIX kernel developers decided to send a SIGPIPE signal, which terminates the process by default, along with returning EPIPE. This papers over the problem without fixing it: the same programs ignore other errors such as EIO. One hopes that the programs have been fixed by now; kernels nevertheless continue to generate the SIGPIPE signal. The first time io\_trywrite or io\_waitwrite is called, it arranges for SIGPIPE to be ignored.  (Technically, for SIGPIPE to be caught by an empty signal handler, so this doesn't affect child processes.) Do not use SIGPIPE elsewhere in the program.

## SEE ALSO

[io\_nonblock(3)](/io_nonblock/3.md), [io\_waitread(3)](/io_waitread/3.md), [io\_trywritetimeout(3)](/io_trywritetimeout/3.md)