Re: Threads vs url-http

[813gan <813gan@protonmail.com>]

On Sunday, September 29th, 2024 at 07:26, Eli Zaretskii <eliz@gnu.org> wrote:

> 
> 
> > Date: Sun, 29 Sep 2024 00:28:36 +0000
> 
> > From: 813gan 813gan@protonmail.com
> > 
> > (require 'url-http)
> > (require 'url-parse)
> > (defun url-retrieve-thread (url)
> > "Wrapper around url-http that download `URL' without blocking main thread."
> > (let* ((parsed-url (if (url-p url) url (url-generic-parse-url url)))
> > (mut (make-mutex))
> > (cond-var (make-condition-variable mut))
> > (buf nil)
> > (cb (lambda (&rest _) (setq buf (current-buffer)) (with-mutex mut (condition-notify cond-var)) )) )
> > (url-http parsed-url cb nil)
> > (with-mutex mut
> > (condition-wait cond-var) )
> > buf))
> > 
> > Idea was to call it from thread. In most trivial case:
> > (make-thread (apply 'url-retrieve-thread "http://example.com" nil))
> 
> 
> You are waiting on a condvar in the same thread which should notify
> the condvar, don't you? The callback passed to url-http will be
> called in the context of the same thread in which url-http was called,
> but that thread is meanwhile blocked in the condition-wait you call
> after url-http.
> 
> AFAIU your intent, you should wait on the condvar in the main thread,
> not in the thread which calls url-http.
> 
> > It makes Emacs unresponsive (even C-g does not work).
> 
> 
> Yes, because it's deadlock: a thread is waiting in a condvar which no
> other thread will call.

Yeah. my understanding of parallelism seems to be worst than i excepted.

Other implementation (naive?) follows.

(defun wiki-read--url-retrieve (url)
  "Wrapper around url-http that download `URL' without blocking thread."
  (let* ((parsed-url (if (url-p url) url (url-generic-parse-url url)))
	 (buf nil)
	 (cb (lambda (&rest _) (setq buf (current-buffer)) )) )
    (url-https parsed-url cb nil)
    (while (not buf) (thread-yield))
    buf))
(make-thread (apply 'wiki-read--url-retrieve "https://google.com" nil))

Why thread-yield don't unblock this?

Thanks