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...
Quote:
It just seems you are fighting a bad fight against programming with unix.
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.