[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] Gnus generalized search, part II

From: Eli Zaretskii
Subject: Re: [RFC] Gnus generalized search, part II
Date: Wed, 26 Apr 2017 12:42:07 +0300

> From: Stephen Leake <address@hidden>
> Date: Mon, 24 Apr 2017 12:17:37 -0500
> > Basically we're sending search queries to multiple
> > servers, and using threads to make the external processes asynchronous.
> > C-g would come into play when one or more of those processes hangs or is
> > slow, and the user loses patience and wants to quit. The desired result
> > would be that whichever thread we're currently waiting on gets killed,
> There should never be _one_ thread that you are waiting on (except when
> there is only one left, of course); you should always be waiting for
> _any_ thread to respond.

Who is "you" in this context that is waiting?  And what is meant by

> Otherwise, you don't have a truly asynchronous system; you have a
> polled synchronous system.

Emacs Lisp threads are indeed not a truly asynchronous system, and
cannot be used to produce any such system, because only one Lisp
thread can be running at any given time.

> So the user would be saying "kill all outstanding threads".

The application could catch C-g and kill threads.  But the question
was what should C-g do without any application code, and the answer
cannot be kill all Lisp threads, because only one thread could ever
receive the C-g keystroke and act on it.

So maybe there's some mismatch of expectations here.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]