Hacker News new | past | comments | ask | show | jobs | submit login

On this topic of stdin, stdout - wouldn't it be neat if - instead of signals - there was an input channel called stdctrl that you could send control messages in on.

Glad to read about the scenario at your last place - I've never seen this in action.




Well those are just the defaults, a program can open a lot more sockets if it wants to. IPC is an old problem with a lot of pretty good solutions by now.


Well, it's not exactly what you describe (which does sound kind of intriguing), but Linux does offer the signalfd(2) syscall, which allows you to read signals from a file descriptor. Doesn't do much for the sender of said signals, however.


At AOL circa 2000, our application framework had a Tcl interpreter listening on a "control port", so that you could telnet to any app and get stats, change settings, etc.

Of course, nowadays that's more commonly done with REST endpoints, which I think would satisfy your stdctrl idea.


I think Plan 9 does something similar. You send signals to a process by writing to a file in the process's /proc directory.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: