>I was just thinking over the weekend how convenient it would be if ls could
>accept a format string to allow customization of the output, much like ps does.

I like this, it's how all key unix utilities should work IMHO.

> Rather than banging everything into a file model so that select() will work,
> I'd just note that with a proper multithreading implementation (where
> individual threads block without blocking the whole process) this kind of
> "watch everything" task can get a lot easier.  (It may not seem so until
> you've programmed with threads, though.)

Not just threads. Now you're asking me to sprinkle mutexes all through my
pre-existing application engine, which is not acceptable.

I suppose I could spawn a thread whose sole purpose is to packetize the event
and write it to an anonymous pipe, which would then be select()ed on and read
by my main event loop. But it annoys me that I have to go to such trouble
when the basic concept of wait() is what's bogus. How many versions of
system() will discard events from a child process they didn't create?

Over the years people have hacked the wait() interface many times, adding
PID specifiers, timeout options, etc., etc. All of this to get around the
fact that somebody, either the parent process or the kernel, has to remember
the wait-status somewhere until it can be dealt with by the parent process.
Or else that wait-status is dropped on the floor and lost.

Signals as used by daemons are subject to a similar gripe: if I am inetd and
I get a SIGHUP, is it safe for me to call the routine to re-read my conf
file immediately (danger will robinson!) or do I have to set a global and
notify my main event loop so the EINTR from select() does not confuse it?

Why didn't I just open /dev/proc/5519/input/SIGHUP and add it to the list
of stuff I select() on for reading? Because /dev/proc thinks of itself as
a replacement for ptrace, and doesn't have any more ambition than that.

Todd Whitesel
toddpw @ best.com