Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Tue, 07 Jan 2014 03:23:32 +0000
From: MRAB <python@mrabarnett.plus.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: python-list@python.org
CC: python-list@python.org
Subject: Re: Trying to wrap my head around futures and coroutines
References: <CANc-5UxzRtBura1ve9tQ5o=RQCasm_VpxewerGLq1_8B0LMpjQ@mail.gmail.com> <20140107022958.GA59457@cskk.homeip.net>
In-Reply-To: <20140107022958.GA59457@cskk.homeip.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.5118.1389065013.18130.python-list@python.org>
Lines: 74
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:63409

On 2014-01-07 02:29, Cameron Simpson wrote:
> On 06Jan2014 18:56, Skip Montanaro <skip.montanaro@gmail.com> wrote:
> [...]
>> Let's say I have a dead simple GUI with two buttons labeled, "Do A" and "Do
>> B". Each corresponds to executing a particular activity, A or B, which take
>> some non-zero amount of time to complete (as perceived by the user) or
>> cancel (as perceived by the state of the running system - not safe to run A
>> until B is complete/canceled, and vice versa). The user, being the fickle
>> sort that he is, might change his mind while A is running, and decide to
>> execute B instead. (The roles can also be reversed.) If s/he wants to run
>> task A, task B must be canceled or allowed to complete before A can be
>> started.
>
> I take it we can ignore user's hammering on buttons faster than
> jobs can run or be cancelled?
>
>> Logically, the code looks something like (I fear Gmail is going to
>> destroy my indentation):
>>
>> def do_A():
>> when B is complete, _do_A()
>> cancel_B()
> [...]
>> def _do_A():
>> do the real A work here, we are guaranteed B is no longer running
> [...]
>> cancel_A and cancel_B might be no-ops, in which case they need to start up
>> the other calculation immediately, if one is pending.
>
> I wouldn't have cancel_A do this, I'd have do_A do this more overtly.
>
>> This is pretty simple execution, and if my job was this simple, I'd
>> probably just keep doing things the way I do now, which is basically to
>> catch a "complete" or "canceled" signal from the A and B tasks and execute
>> the opposite task if it's pending. But it's not this simple. In reality
>> there are lots of, "oh, you want to do X? You need to make sure A, B, and C
>> are not active." And other stuff like that.
>
> What's wrong with variations on:
>
>    from threading import Lock
>
>    lock_A = Lock()
>    lock_B = Lock()
>
>    def do_A():
>      with lock_B():
>        with lock_A():
>          _do_A()
>
>    def do_B():
>      with lock_A():
>        with lock_B():
>          _do_B()
>
It's safer to lock in the same order to reduce the chance of deadlock:

     def do_A():
       with lock_A():
         with lock_B():
           _do_A()

     def do_B():
       with lock_A():
         with lock_B():
           _do_B()

> You can extend this with multiple locks for A,B,C provided you take
> the excluding locks before taking the inner lock for the core task.
>
> Regarding cancellation, I presume your code polls some cancellation
> flag regularly during the task?
>