|
From: | Alexander Miller |
Subject: | Re: Questions about throw-on-input |
Date: | Sat, 9 May 2020 15:09:58 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 |
[I had to copy the In-Reply-To header from the page source because the reply-to button wouldn't set it, so let's hope I'm doing this right.] Incidentally I have recently been playing around with a similar idea - to use a worker thread to split and run long tasks in the background. Here's what I came up with so far: (defconst worker-mutex (make-mutex "*WORKER MUTEX*")) (defconst worker-cond-var (make-condition-variable worker-mutex)) (defvar worker-queue (list)) (setf worker (make-thread (lambda () (while t (while worker-queue (let* ((work-unit (pop worker-queue)) (fn (car work-unit)) (args (cdr work-unit))) (apply fn args) (thread-yield))) (with-mutex worker-mutex (condition-wait worker-cond-var)))) "*WORKER*")) (setf worker-timer (run-with-idle-timer 1 t (lambda () (when worker-queue (with-mutex worker-mutex (condition-notify worker-cond-var)))))) (push (list #'shell-command-to-string "notify-send 'Hello' 'World!'") worker-queue) (push (list #'message "Hello %s!" "World") worker-queue) (push (list #'call-interactively #'treemacs) worker-queue) Get enough thread-yield or input-pending checks into the work the thread is doing and you might just be able to get around blocking the UI despite having plenty to do.
[Prev in Thread] | Current Thread | [Next in Thread] |