Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add API to completely disable librpm's use of Unix signal handlers
On Tue, Feb 17, 2015, at 07:07 AM, Florian Festi wrote: > Sorry, for the last response. DevConf takes its toll... > > On 01/23/2015 04:07 AM, Colin Walters wrote: > > Numerous consumers of librpm use it in a pattern where they're > > constructing fresh chroots. For example, rpm-ostree operates this > > way, and is used to provide atomic upgrades in concert with rpm. > > > > If the process dies due to SIGINT or another signal, the root can > > simply be discarded. > > > > Currently today, rpm-ostree undoes the signal handlers after loading > > librpm so that Control-C does what I want, but there's still a race > > condition where the interrupt can be lost. > > > > Add an API so callers can disable the behavior. > > Is there any chance someone would want to switch them back on? I can't think of one offhand...tools that interact with a live root should be happy with what RPM does today, right? > My gut > feeling tells me this should rather be rpmsqSetInterruptSafety(int on); But here's a patch which does it, in case you prefer it. I did write a better API doc this time. From ae6d2de85b7b81cf91318183ba253402ac538785 Mon Sep 17 00:00:00 2001 From: Colin Walters <[email protected]> Date: Thu, 22 Jan 2015 17:57:14 -0500 Subject: [PATCH] Add API to disable librpm's use of Unix signal handlers Numerous consumers of librpm use it in a pattern where they're constructing fresh chroots. For example, rpm-ostree operates this way, and is used to provide atomic upgrades in concert with rpm. If the process dies due to SIGINT or another signal, the root can simply be discarded. Currently today, rpm-ostree undoes the signal handlers after loading librpm so that Control-C does what I want, but there's still a race condition where the interrupt can be lost. Add an API so callers can disable the behavior.
- Loading branch information