Re: [pacman-dev] download interrupt mechanism
To not block the GUI, I run trans_commit function in a g_thread and I can't use SIGINT signal. I have no way to correctly stop curl process. I propose to look for a particular value to do it as transaction functions do with TRANS_STATE_INTERRUPTED.Dave Reisner <d@falconindy.com> a écrit :On Aug 25, 2015 7:04 AM, "Guillaume Benoit" <guillaume@manjaro.org> wrote:
Hi, working on a GUI frontend for libalpm, I noticed that download process
lakes for an internal interrupt mechanism. Download cancellation is only handled by catching SIGINT signal.
I think it would be a benefit for libalpm to have more correct download interrupt mechanism like trans_interrupt handle package transaction cancellation.
Could you explain more about why signal handling is non-ideal? What would trans_interrupt do differently? What problems does this solve?
I'm already working on a patch and I would like to know if you would interested in adding this feature to libalpm. Regards.
Without knowing more details on what you're proposing, its hard to say.
On Tue, Aug 25, 2015 at 09:21:50PM +0200, Guillaume wrote:
To not block the GUI, I run trans_commit function in a g_thread and I can't use SIGINT signal. I have no way to correctly stop curl process. I propose to look for a particular value to do it as transaction functions do with TRANS_STATE_INTERRUPTED.Dave Reisner <d@falconindy.com> a écrit :On Aug 25, 2015 7:04 AM, "Guillaume Benoit" <guillaume@manjaro.org> wrote:
Please don't top post. Presumably, you can't use SIGINT because you can't guarantee which thread the signal is delivered to. You need to properly guard against this situation by blocking SIGINT on threads which aren't the caller of trans_commit. With only 1 thread not masking SIGINT, the linux kernel will guarantee delivery to this thread. http://stackoverflow.com/a/11679770 Is this correct? Or is there some other reason that you can't rely on signal delivery as an interrupt mechanism? d
Le 25/08/2015 23:34, Dave Reisner a écrit :
On Tue, Aug 25, 2015 at 09:21:50PM +0200, Guillaume wrote:
To not block the GUI, I run trans_commit function in a g_thread and I can't use SIGINT signal. I have no way to correctly stop curl process. I propose to look for a particular value to do it as transaction functions do with TRANS_STATE_INTERRUPTED.Dave Reisner <d@falconindy.com> a écrit :On Aug 25, 2015 7:04 AM, "Guillaume Benoit" <guillaume@manjaro.org> wrote:
Please don't top post.
Presumably, you can't use SIGINT because you can't guarantee which thread the signal is delivered to. You need to properly guard against this situation by blocking SIGINT on threads which aren't the caller of trans_commit. With only 1 thread not masking SIGINT, the linux kernel will guarantee delivery to this thread.
http://stackoverflow.com/a/11679770
Is this correct? Or is there some other reason that you can't rely on signal delivery as an interrupt mechanism?
d
Yes, maybe I can do that but won't it be better for a library to not have to use signals ? Knowing that alpm_trans_commit function runs download then packages transaction, won't it be clearer to have a unique function to cancel the process ? alpm_trans_interrupt function can already be used to cancel package transaction, my idea is to complete it to also cancel downloads. Guillaume.
participants (3)
-
Dave Reisner
-
Guillaume
-
Guillaume Benoit