[Top][All Lists]

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

Re: Concurrency via isolated process/thread

From: Po Lu
Subject: Re: Concurrency via isolated process/thread
Date: Sun, 09 Jul 2023 08:37:47 +0800
User-agent: Gnus/5.13 (Gnus v5.13)

Eli Zaretskii <eliz@gnu.org> writes:

> Are they allowed to, say, write some data to a file?  If so, they
> might need to ask the user whether its okay to overwrite an existing
> file.

They might chose to use `write-region' instead, or save the file from
the main thread.

> IOW, I think you have a very narrow idea of "number and text crunching
> tasks" that could benefit from threads.  For example, one of the
> frequent requests is to run the part of Gnus that fetches email and
> articles in a separate thread -- if this is okay for "number and text
> crunching tasks", then it is likely to prompt users.

Prompting for options should take place before the thread is started, or
after the data is retrieved and about to be displayed.

> We are mis-communicating.  My point is that it is almost impossible to
> take an existing non-trivial Lisp program and let it run from a
> non-main thread without bumping into this issue.  Your responses
> indicate that you agree with me: such Lisp programs need to be written
> from scratch under the assumption that they will run from a non-main
> thread.

I agree with this completely.  From my POV, such requirements are
reasonable and not very different from the requirements for doing so in
other GUI toolkits and programs.

> How is this compatible with the goal of having threads in Emacs, which
> are to allow running Lisp code with less hair than the existing timers
> or emacs-async?

I thought the concern was one of efficiency, and not ease of use:
process IO is slow compared to sharing the same VM space, and
subprocesses also utilize more memory.

>> > Fixed how?
>> By replacing `sit-for' with `sleep-for' (and in general avoiding
>> functions that call redisplay or GUI functions.)
> So programs running in non-main threads will be unable to do stuff
> like show progress etc.?  That's not very encouraging, to say the
> least.

They should be able to run code from the main thread's command loop, via
mechanisms such as `unread-command-events'.

> This basically means rewriting most of Emacs.  Because most APIs and
> subroutines we use in every Lisp program were not "specifically
> written for running outside the main thread".  So we'll need special
> variants of all of those to do those simple jobs.

I wasn't thinking about Lisp functions used for text editing tasks, but
rather raw data crunching functions.  Most of these are already
side-effect free, and some are even truly reentrant.

reply via email to

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