This is the mail archive of the
mailing list for the newlib project.
Re: Nonblocking UART driver using _write_r - error if no data was written?
- From: Freddie Chopin <freddie_chopin at op dot pl>
- To: newlib at sourceware dot org
- Date: Wed, 26 Feb 2014 12:47:00 +0100
- Subject: Re: Nonblocking UART driver using _write_r - error if no data was written?
- Authentication-results: sourceware.org; auth=none
- References: <CAMym-+z-1ABKQnJaR_eKDTxqk_+0ZgeGdnq_++efJGTBy6o2yA at mail dot gmail dot com> <CAMym-+wVa4HiMNj_LbriWV1WnroxNuNYPnkAe_K24g7EFiMk0Q at mail dot gmail dot com>
W dniu 2014-02-26 12:30, MikuslawProxy pisze:
I was wandering if I should ask on you website first, but I see that
it came to the same thing.
As for the clue of discussion: I use open(...) without flags to open
the device. I do it using the _open_r stub as it was described on
different websites - _open_r redirects the open call to specific
device open() call. I'm under the impression that if I use it this
way, the O_NONBLOCK flag would have to be interpreted by my driver,
not the newlib, so if I'm running always in nonblocking mode it will
not change anything.
The fopen call could change something, but in newlib code in version
2.1.0 only references I see to NONBLOCK are in mq_open code etc.
Nothing that seems to touch normal stdin/stdout.
Good point. If newlib does not store any specific flag that marks the
stream as non-blocking then indeed this makes no difference in your case.
I think that a question I start to ask myself is if newlib is even
capable of flushing to nonblocking device. Also, what is the rationale
behind doing (fflush.c:193):
I guess some rationale is here:
When attempting to write to a file descriptor (other than a pipe or
FIFO) that supports non-blocking writes and cannot accept the data
If the O_NONBLOCK flag is set, write() shall not block the thread. If
some data can be written without blocking the thread, write() shall
write what it can and return the number of bytes written. Otherwise,
it shall return -1 and set errno to [EAGAIN].
In your case "no data can be written", so the functions return -1. I've
recently thought about write()/read() implementations in POSIX and I'm
under impression that 0 can be returned only if you request a write of 0
bytes. If you request to write anything, the only possible return values
are -1 if nothing was written (errno set to EAGAIN) or a positive value
with number of bytes written (I'm not considering any actual errors to
make it simpler).