[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: inotifyd problems
From:       Rob Landley <rob () landley ! net>
Date:       2008-12-21 7:06:13
Message-ID: 200812210106.14173.rob () landley ! net
[Download RAW message or body]

On Thursday 27 November 2008 12:00:11 Vladimir Dronnikov wrote:
> > According to http://www.linuxjournal.com/article/8478 - close() will do
> > all the required cleanup job.
>
> It was you, Piotr, who requested for ...to have inotify_rm_watch() for each
> inotify_add_watch() call... :)
> I, personally, turn FEATURE_CLEAN_UP off and rely upon the system
> housekeeping.

FEATURE_CLEAN_UP exists for two reasons:

1) People building for "bare metal" targets like newlib+libgloss haven't got 
an OS cleaning up after them.

2) People running busybox under valgrind complained that it would bury them in 
resource leak messages on exit, so they wanted an option to shut it up.

In theory, the FEATURE_CLEAN_UP code theoretically gives you more applets that 
can be run as function calls (without forking) from the busybox shell.  In 
reality, if anything like xread() ever hits an error and calls exit() that 
would take down your shell.

I once sketched out some in toybox to substitute a longjmp() for the exit() 
and register the various resources on linked lists to free() and close() and 
munmap() and so on, but the complexity of doing this kind of makes the benefit 
of nofork dubious at best.  (The OS already _has_ this cleanup code, and it 
has to work, so the _simple_ thing is to use it rather than try to reimplement 
it badly.)

Rob
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]