> atexit() is evil. Is there another BB approved way to work with lock files cleanly? To set handlers for all signals to prevent program occasional termination? Isn't it too bloaty? Especially when used in multiple applets.
List! Let us invent a library function to deal with lock files. -- Vladimir 2008/2/3, Denis Vlasenko <[EMAIL PROTECTED]>: > On Sunday 03 February 2008 10:10, Vladimir Dronnikov wrote: > > Hello! > > > > I've prepared a set of patches. > > Great. But please send them one per email. > > > 1. mkswap: remove unnecessary rewind when getting length of swap device > > ok, applied. > > > 2. mount: support mount helpers. E.g. mount -t ntfs-3g /dev/hda1 /mnt > would > > first try to exec ntfs-3g binary and if it fails then try to issue > mount(2). > > char *args[4] should be char *args[6]. Otherwise ok, applied. > > > 3. new xmklock(char *lock_file_name) function. It dies if lock_file_name > > file already exists. Otherwise it creates that file and securely deletes > it > > on exit. > > This function is then used by 2 BB applets: microcom and [send|fetch]mail. > > atexit is evil (*big* problems with NOFORK etc). Please avoid. > > > 4. microcom: now it properly works on piped stdin. Denys, please consider > > applying > > Depends on xmklock... > > > 5. sendmail: converted to sendmail+fetchmail. The latter simply pulls > remote > > mailbox content into local Maildir. > > Fetchmail is being actively developed so any comments are welcome! > > Depends on xmklock... > -- > vda > _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
