On 11.03.2015 17:24, Laurent Bercot wrote:
On 11/03/2015 17:10, Harald Becker wrote:
And what is wrong with a long lived daemon?
Ok, what I see is brain damaged developers writing big monolithic
long lived daemons, which suck up tons of memory and / or cpu power
:( ...
... this is not what I understand of a carefully designed long lived
daemon ... it is silliness pure ...
... on the other hand, long lived daemons are no problem, as long as
they stay at low resource usage ... and don't try to do too
complicated things in a single process (multi threaded or not).
Yes, exactly my point.
And exactly the reason why I think a long-lived uevent handler is
good design and that respawns are unnecessary. ;)
Ok, now we can start discussing what is big or small, complicated or
simple ;) ... a friend answered that question with "size and usage
always matters" ... but ok, that was to a different (not computer
related topic) :)
I like to be a bit more picky keeping simple, and in freeing memory when
not used. So I try to split of such things in a listener and a consumer
/ handler process. Like network connection listeners (e.g. tcpsvd),
which accept incoming connections and spawn handler process for this
incoming request.
For the netlink uevent handling stuff, this would be more like gathering
information from netlink socket then forwarding this message to the
handler. Not including conf parser and device node operation in the long
lived daemon (that is handler part).
--
Harald
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
