unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: "Stefan Monnier" <monnier@iro.umontreal.ca>,
	"João Távora" <joaotavora@gmail.com>
Cc: 41531@debbugs.gnu.org, andreyk.mad@gmail.com
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Date: Sat, 6 Jun 2020 04:57:29 +0300	[thread overview]
Message-ID: <63d261d3-62e5-8c60-f191-8734aa37752b@yandex.ru> (raw)
In-Reply-To: <jwvzh9u4uju.fsf-monnier+emacs@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 1504 bytes --]

Hi!

On 26.05.2020 17:53, Stefan Monnier wrote:
>> But really: now we have deadlock too?  I just want to solve this
>> problem: please let's commit something, and move on to the next bug.
> Can you use the sample `eldoc-future-*` code I sent earlier?

How about the attached file for a rough, but a largely feature complete 
first version of futures?

To remind from previous discussions, we wanted futures:

- To be cancelable, so that the issuer could abort their calculations, 
if they so desire.
- Force-able, meaning the consumer should be able to "realize" the 
future synchronously, with the future's creator being able to support 
their, most optimal, version of that logic. The default needs to be 
useful and reliable enough, though, that callers could use it in 99% of 
cases anyway.

The error callback probably wasn't mentioned, but it seems logical to 
have it anyway.

For the first two features, I also considered using cl-generic, but 
result might turn out to be clunkier, and we need overridability only 
for two of these functions. But suggestions welcome.

TBD:

- Probably rename to "promises" in the end.
- It would be nice to have a certain degree of compatibility with 
Christopher Wellons's emacs-aio, so that its promises could be accepted 
by code that expects "our" futures/promises. Not sure if we can do that 
without making the API more complex (aio-resolve's signature comes to 
mind), or if we adopt its approach, importing the package wholesale 
might make more sense.

[-- Attachment #2: future.el --]
[-- Type: text/x-emacs-lisp, Size: 2549 bytes --]

;;; future.el --- Futures, a concurrency primitive   -*- lexical-binding: t; -*-

;; Copyright (C) 2020  Dmitry Gutov

;; Author: Dmitry Gutov <dgutov@yandex.ru>
;; Keywords: lisp

;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with this program.  If not, see <https://www.gnu.org/licenses/>.

;;; Commentary:

;;

;;; Code:

(require 'cl-lib)

(cl-defstruct (future
               (:conc-name future--)
               (:constructor future-make (&key force-fn
                                               cancel-fn)))
  "This structure represents a \"future\" value."
  value
  error
  (status 'pending)
  (force-fn #'future-force--apo)
  (cancel-fn #'ignore)
  callback
  errback)

(defun future-force (f)
  (funcall (future--force-fn f)))

(defun future-force--apo (f)
  (while (eq (future--status f) 'pending)
    (accept-process-output nil 0.05)))

(defun future-cancel (f)
  (when (eq (future--status f) 'pending)
    (setf (future--status f) 'canceled)
    (funcall (future--cancel-fn f))))

(defun future-set (f v)
  ;; FIXME: Probably shouldn't error on 'canceled'.
  (cl-assert (eq (future--status f) 'pending))
  (setf (future--value f) v
        (future--status f) 'success)
  (when (future--callback f)
    (funcall (future--callback f) v)))

(defun future-error (f e)
  ;; FIXME: Probably shouldn't error on 'canceled'.
  (cl-assert (eq (future--status f) 'pending))
  (setf (future--error f) e
        (future--status f) 'error)
  (when (future--errback f)
    (funcall (future--errback f) e)))

;; Or we can make these both lists of functions...
(defun future-set-callback (f c)
  (cl-assert (null (future--callback f)))
  (setf (future--callback f) c)
  (when (eq (future--status f) 'success)
    (funcall c (future--value f))))

;; ...and rename to -add-callback/-add-errback.
(defun future-set-errback (f c)
  (cl-assert (null (future--errback f)))
  (setf (future--errback f) c)
  (when (eq (future--status f) 'error)
    (funcall c (future--error f))))

(provide 'future)
;;; future.el ends here

  parent reply	other threads:[~2020-06-06  1:57 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-25 17:04 bug#41531: 27.0.91; Better handle asynchronous eldoc backends João Távora
2020-05-25 23:52 ` Dmitry Gutov
2020-05-26  1:21   ` João Távora
2020-05-26 13:57     ` Dmitry Gutov
2020-05-26 16:03       ` João Távora
2020-05-26 19:14         ` Dmitry Gutov
2020-05-26 20:00           ` João Távora
2020-05-27 21:14             ` Dmitry Gutov
2020-05-27 22:13               ` João Távora
2020-05-27 23:35                 ` Dmitry Gutov
2020-05-27 23:57                   ` João Távora
2020-05-26  2:38   ` Stefan Monnier
2020-05-26 11:22     ` João Távora
2020-05-26 14:53       ` Stefan Monnier
2020-05-26 15:19         ` João Távora
2020-05-26 15:56           ` Stefan Monnier
2020-05-26 16:26             ` João Távora
2020-05-26 17:39               ` Stefan Monnier
2020-05-26 18:49                 ` João Távora
2020-06-03  2:45                   ` Stefan Monnier
2020-06-03 18:07                     ` João Távora
2020-06-03 20:22                       ` Stefan Monnier
2020-06-03 20:36                         ` João Távora
2020-06-03 21:21                           ` Stefan Monnier
2020-06-05 11:26                             ` João Távora
2020-06-03 21:28                       ` Dmitry Gutov
2020-06-06  1:57         ` Dmitry Gutov [this message]
2020-05-26 13:32     ` Dmitry Gutov
2020-05-26 16:56       ` João Távora
2020-06-03 18:56 ` bug#41531: 28.0.50; proper Eldoc async support João Távora
2020-06-04 16:20   ` Andrii Kolomoiets
2020-06-04 18:22     ` Dmitry Gutov
2020-06-04 19:00       ` Andrii Kolomoiets
2020-06-05 22:53         ` João Távora
2020-06-05 11:00     ` João Távora
2020-06-05 17:50       ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-06-05 23:25         ` João Távora
2020-06-05 23:28         ` João Távora
2020-06-11 11:11       ` Andrii Kolomoiets
2020-06-30 11:31 ` bug#41531: 27.0.91; Better handle asynchronous eldoc backends João Távora
2020-07-04  7:45   ` Eli Zaretskii
2020-07-04  9:21     ` João Távora
2020-07-04  9:31       ` Eli Zaretskii
2020-07-04  9:37         ` João Távora
2020-07-04  9:44           ` Eli Zaretskii
2020-07-04 11:00     ` João Távora
2020-07-04 21:06       ` Dmitry Gutov
2020-07-04 23:12         ` João Távora
2020-07-07  0:43           ` Dmitry Gutov
2020-07-07 10:58             ` João Távora
2020-07-07 14:18               ` Dmitry Gutov
2020-07-07 14:34                 ` João Távora
2020-07-05 12:03     ` João Távora
2020-07-05 15:09       ` Eli Zaretskii
2020-07-05 15:13       ` Stefan Monnier
2020-07-04 10:04   ` Dmitry Gutov
2020-07-04 11:48     ` João Távora
2020-07-04 21:27       ` Dmitry Gutov
2020-07-04 21:30         ` Dmitry Gutov
2020-07-04 23:07         ` João Távora
2020-07-07  3:01           ` Dmitry Gutov
2020-07-07 10:56             ` João Távora
2020-07-07 12:23               ` João Távora
2020-07-07 13:38               ` Stefan Monnier
2020-07-07 14:24                 ` Dmitry Gutov
2020-07-07 16:07                   ` Stefan Monnier
2020-07-07 23:11                     ` Dmitry Gutov
2020-07-08  3:58                       ` Stefan Monnier
2020-07-08 11:20                         ` Dmitry Gutov
2020-07-08 13:25                           ` Stefan Monnier
2020-07-08 13:41                             ` João Távora
2020-07-08 14:21                             ` Dmitry Gutov
2020-07-08 15:12                               ` João Távora
2020-07-08 18:32                                 ` Dmitry Gutov
2020-07-08 19:12                                   ` Eli Zaretskii
2020-07-07 14:45                 ` João Távora
2020-07-07 14:40               ` Dmitry Gutov
2020-07-07 22:24               ` Dmitry Gutov
2020-07-07 22:49                 ` João Távora
2020-07-07 23:00                   ` Dmitry Gutov
2020-07-07 23:24                     ` João Távora
2020-07-07 23:42                       ` Dmitry Gutov
2020-07-07 23:46                         ` João Távora
2020-07-08  0:10                           ` Dmitry Gutov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=63d261d3-62e5-8c60-f191-8734aa37752b@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=41531@debbugs.gnu.org \
    --cc=andreyk.mad@gmail.com \
    --cc=joaotavora@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).