GNU bug report logs - #38807
[Feature request]: Support lisp workers like web workers.

Previous Next

Full log

Message #143 received at 38807 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: HaiJun Zhang <netjune <at> outlook.com>
Cc: 38807 <at> debbugs.gnu.org, michael.albinus <at> gmx.de
Subject: Re: bug#38807: [Feature request]: Support lisp workers like web
 workers.
Date: Sat, 04 Jan 2020 10:59:45 +0200

> Date: Sat, 4 Jan 2020 13:19:46 +0800
> From: HaiJun Zhang <netjune <at> outlook.com>
> Cc: michael.albinus <at> gmx.de, 38807 <at> debbugs.gnu.org
> 
>  How do you write a useful Lisp application for a thread if you have no
>  way of displaying any messages?  
> 
> Workers are background workers. They don’t display messages directly. They post the error messages to the
> UI part of the lisp application.

How would that work?  We don't have any such message queues in Emacs,
and no machinery to display them, nor for telling the user which job
reported the message.

And again, some low-level Lisp functions issue messages when they like
that, out of the application's control.  What do you do with those?

> For a lisp application such as an email client, it is splitted to two parts: the UI part and the worker part. The UI
> part may has two callbacks(or event handlers):
> 1. on_new_email
> 2. on_error
> 
> If the worker fetches an email successfully, it sends an event to the UI part and the on_new_email callback of
> the UI part will be called. If the worker fails, it sends an error to the UI part and the on_error callback will be
> called. The on_error callback can display the error message to user.

I'm saying that fetching email doesn't need any Lisp, it can be done
in C.  And if so, you don't need Lisp-level threads at all.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.