Programming

I use read(), not fread(). read() could for example only return 1 byte. As all available docs say, that read() *can* return less bytes then requested. So the return value of the read() call in your case would be 1 (in my optinion). Then a program would decide to either

Thank you, didn't know that page. This really helped, since it confirmed my expectations and prove all other posters here wrong (no offence)

EDIT: well, not about the thing with the first write after opening a file. But that is not that important anyway. And nobody disputed that

After some further reading, I found out that all this is not true for regular files. select() behaves as if a file is ready for reading and writing at any time:

"File descriptors associated with regular files shall always select true for ready to read, ready to write, and error conditions."

select

This makes Unix more inconsistent than I thought. Most documents about select don't mention that. I guess it's a "they won't notice" thing. Also, O_NONBLOCK does not work with regular files. I didn't want to do multithreading or multiprocessing to conserve resources. For the same reason I can't use aio_read(), because on Linux it is implemented with threads. The kernel does not support async I/O. This is a suboptimal solution in my opinion, because only the kernel knows, which operations would make sense to do in parallel (because the files might be on different disks)... I'm gonna write my own kernel

But I think I can live with all that. I just need to look out, that my file I/O operations are small, so they don't block for long.

Good luck.

You stated that you don't want to set O_NONBLOCK
which is standard to *nix for alleviating blocking behaviors
and is the basis for fast event interfaces like kqueue and
epoll for sockets, pipes, etc...
You don't want to use threads or processes to allow
for blocking on reads and writes to regular files due to
resource conservation.
Finally, you state that you believe that as long as i/o operations are
'small' you should be okay (as if this somehow alleviates the wait
behavior incurred should an operation block..).
It just seems you are fighting a bad fight against programming with unix.

Here's a little advice:
Optimization (computer science - Wikipedia, the free encyclopedia)

Yes, I realized that given the alternatives I have to "die one death". I think I will make a single threaded app, that multiplexes sockets using select(). File operations will then still block, but if I keep them small, they should not hurt performance much. After all, file I/O should be much faster then network I/O. At least in max. 20 ms every small file read should be finished.

Its just that I realized now, that neither select() nor O_NONBLOCK ("standard to *nix for alleviating blocking behaviors") work for ordinary files (I mean, who would have thought?)

By the way, as long as you don't use ordinary files, O_NONBLOCK is not needed. select() does it's job very well even without O_NONBLOCK. On the other hand, if you use select(), O_NONBLOCK is not really needed anymore. Read man select_tut(2) on this.

So the only alternative would be threading. But this solves only part of the problem, because file operations would be asynchrouos with the select part of my app, but not with each other. Who knows, one file could still be in cache by the time it's needed...

That's why I'm here, right?

btw, your little advice is neither little nor an advice

You mean I'm trying to optimize too soon? I don't think so, because in this case I try to figure out a good overall structure for the app. This is better done before I write the bulk of code.

Hello,

This is one of the well known *nix gotchas.
Most unix systems programmers have gotten used to it.
Not that it's ideal.

"
Read or write not blocking on a resource after select returns is not entirely reliable at all times. The select_tut example is it's own best argument against using the non-blocking model imho. Also see: http://cr.yp.to/unix/nonblock.html

You are ,imo, optimizing too soon and encountering problems that research may have
ameliorated. Please see if you haven't already: The C10K problem

Hi, this is jack Steven. I have an Interest to answers the questions on JAVA. If any one want to or interest in asking questions, you are welcome.
--------------------------------
Jack Steven