Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Date: Tue, 7 Jan 2014 13:29:58 +1100
From: Cameron Simpson <cs@zip.com.au>
To: Skip Montanaro <skip.montanaro@gmail.com>
Subject: Re: Trying to wrap my head around futures and coroutines
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CANc-5UxzRtBura1ve9tQ5o=RQCasm_VpxewerGLq1_8B0LMpjQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
References: <CANc-5UxzRtBura1ve9tQ5o=RQCasm_VpxewerGLq1_8B0LMpjQ@mail.gmail.com>
Cc: Python <python-list@python.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.5113.1389061809.18130.python-list@python.org>
Lines: 66
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:63404

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()

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?

Cheers,
-- 
Cameron Simpson <cs@zip.com.au>

Many are stubborn in pursuit of the path they have chosen, few in pursuit
of the goal. - Friedrich Nietzsche