Non-blocking native files access - single-threaded daemon in C?

Question

I've found out that native files access has no "non-blocking" state. (I'm correct?)

I've been googling for daemons which are "non-blocking", and I've found one which achieved said behavior by threading file access operations, so that the daemon won't block.

My question is, wouldn't threading and IPC'ing such operations be rather expensive? wouldn't it make more sense to either: A) Pre-thread pool, simply have each client at a thread and let it block for which ever blocking operations it might need. Or,

B) In case of file access blocking, use a relatively small buffer, that way it's still blocking - but one would assume that a tiny buffer for multiple operations would make more sense than paying the price of threading each operation and IPC it?

Answer 1

If you use threading, little IPC overhead is needed. You have the same memory space for all your threads, so a simple mutex or semaphore may be all you need. Now, if you are blocking on a mutex or semaphore too long or too often, why use async I/O in the first place?

As to the actual computation performed by threads doing I/O, they are waiting for the kernel to wake them up most of the time, so I wouldn't worry.

If your application is going to revolve around reading files and other I/O sources, you may want to read up on Reactor patterns, and event-driven programming.

Also, you mentioned a daemon, and servicing clients. If the service you provide is reading files, the computational cost of spawning a new thread to serve each client is minimal, since each individual thread will take "long" to complete requests, and block most of the time anyway. There may be a memory problem if your client count is in the thousands, but otherwise I think you'll do okay.

Give us a little more detail about what you want to do, maybe there are more straightforward ways.