[Top][All Lists]

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

Re: multithreading in Elisp?

From: Kai Großjohann
Subject: Re: multithreading in Elisp?
Date: Fri, 06 Jun 2003 14:10:10 +0200
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux)

Florian von Savigny <address@hidden> writes:

> address@hidden (Kai Großjohann) writes:
>> You can do cooperative multitasking, MacOS-style, by using timers or
>> process filters or the like.  (MacOS means before X.)
> Do you have an (arbitrary) code example at hand? My imagination does
> not reach far enough to implement commands that run in parallel by
> means of a process filter (maybe you mean "outsourcing" the task that
> is to run in the background with start-process?). I have no idea, on
> the other hand, what a timer is (it doesn't have to do with the diary,
> does it ... ?).

I think it's not necessary to use a lot of imagination.

Timers are part of Emacs.  For example, the following is good for

(defun tea-time ()
  (message "It's time for tea!"))
(run-at-time "5:00pm" nil 'tea-time)

In addition to run-at-time, also see run-with-timer and
run-with-idle-timer.  Also note that run-at-time allows you to run
the function repeatedly, every second, say.

Process filters are indeed used when you want to communicate with a
process.  When the process creates some output, your process filter
function will be called with a string arg, the arg contains the
output from the process.  You can then do whatever you like and return.

> I would not really care whether the multitasking is preemptive or
> cooperative, as long as the possibility is there at all. What I would
> like to achieve is to have emacs retrieve some text from an external
> program and write it in a different buffer, while it still allows the
> user to edit his text.

This is really easy: you can start a process with start-process.
Then, from time to time, you can call accept-process-output to read
output from that process, or you can use a process filter which just
appends the output to the end of the buffer.

Or you run the process via comint, as has been suggested before in
this thread.  I think that's not a bad solution; it's a fairly
high-level facility.

This line is not blank.

reply via email to

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