unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Pip Cet <pipcet@gmail.com>
Cc: 36609@debbugs.gnu.org, politza@hochschule-trier.de
Subject: bug#36609: 27.0.50; Possible race-condition in threading implementation
Date: Sat, 13 Jul 2019 09:50:02 +0300	[thread overview]
Message-ID: <83wogm1l9h.fsf@gnu.org> (raw)
In-Reply-To: <CAOqdjBe=7cofDzhc2as0x50akNRVxid73QnLQGGRfdOap12R3w@mail.gmail.com> (message from Pip Cet on Fri, 12 Jul 2019 19:30:34 +0000)

> From: Pip Cet <pipcet@gmail.com>
> Date: Fri, 12 Jul 2019 19:30:34 +0000
> Cc: politza@hochschule-trier.de, 36609@debbugs.gnu.org
> 
> > > > We should either release the global lock before the thread exits, or
> > > > defer the acting upon the signal until later.  We cannot disable the
> > > > signal handling altogether because it is entirely legitimate to signal
> > > > another thread, and when we do, that other thread will _always_ be
> > > > inside thread_select.
> > >
> > > Really? What about thread-yield?
> >
> > What about it?
> >
> > You are asking whether, when thread-signal is executed, the thread
> > which we are signaling is necessarily parked inside thread_select?  If
> > so, I don't understand your surprise: only one thread can ever be
> > running, and that is by definition the thread which calls
> > thread-signal.  All the other threads cannot be running, which means
> > they are parked either in thread_select or in sys_mutex_lock called
> > from acquire_global_lock.  Right?
> 
> No, they might also be in the sys_thread_yield syscall, having
> released the global lock but not yet reacquired it:
> 
>   release_global_lock ();
>   sys_thread_yield (); <<<<< here
>   acquire_global_lock (self);

OK, but that, too, means the thread being signaled is not running,
right?  And I still think that a very frequent case, perhaps the most
frequent, is that the thread being signaled is inside thread_select.

> I'm not sure how it's relevant to assert that "that other thread will
> _always_ be inside thread_select".

OK, we've now established that the other thread could also be in
acquire_global_lock or (for a very short time) in sys_thread_yield.

> I have an idea where you might be going with that

I was merely pointing out that we cannot disable the signal handling
as a means to solve the problem.

> but that idea wouldn't work (to release the lock from the signalling
> thread, not the signalled thread that holds it).

Maybe we have a misunderstanding here.  I was talking about this part
of post_acquire_global_lock:

   /* We could have been signaled while waiting to grab the global lock
      for the first time since this thread was created, in which case
      we didn't yet have the opportunity to set up the handlers.  Delay
      raising the signal in that case (it will be actually raised when
      the thread comes here after acquiring the lock the next time).  */
  if (!NILP (current_thread->error_symbol) && handlerlist)
    {
      Lisp_Object sym = current_thread->error_symbol;
      Lisp_Object data = current_thread->error_data;

      current_thread->error_symbol = Qnil;
      current_thread->error_data = Qnil;
      Fsignal (sym, data);
    }

In this part, we have already switched to the thread that has been
signaled, so we are in the signaled thread, not in the signaling
thread.  I meant to release the lock before the call to Fsignal here.

> > If the problem with missing events,
> > then which events are those, and what bad things will happen if we
> > miss them?
> 
> All events that glib knows about but Emacs doesn't. For example, a
> glib timeout is apparently used to achieve some kind of scroll effect
> on GTK menus, which is why we call xg_select from xmenu.c.
> 
> I don't know which libraries use glib-based threads, but I think dbus does, too.
> 
> I believe, but am not certain, that this also includes X events when
> using GTK. That would explain the frozen sessions.

So is the problem that the Glib context is locked "forever", or is the
problem that it's locked by another Lisp thread, even if this lock is
short-lived?  If the former, then arranging for the release of that
lock when the signaled thread exits would solve the problem, right?
And if the problem is the latter one, then why didn't we hear about
this much earlier?  Can you show the bad effect from missing these
events without signaling a thread?

Thanks.





  reply	other threads:[~2019-07-13  6:50 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-11 20:51 bug#36609: 27.0.50; Possible race-condition in threading implementation Andreas Politz
2019-07-12  7:47 ` Eli Zaretskii
2019-07-12  8:05   ` Eli Zaretskii
2019-07-12  9:02 ` Pip Cet
2019-07-12 12:42   ` Eli Zaretskii
2019-07-12 12:57     ` Pip Cet
2019-07-12 13:31       ` Eli Zaretskii
2019-07-12 13:51         ` Pip Cet
2019-07-12 15:05           ` Eli Zaretskii
2019-07-12 18:06             ` Pip Cet
2019-07-12 18:27               ` Eli Zaretskii
2019-07-12 18:34                 ` Eli Zaretskii
2019-07-12 19:24                   ` Pip Cet
2019-07-12 19:57                     ` Eli Zaretskii
2019-07-13 14:37                       ` Pip Cet
2019-07-13 15:03                         ` Eli Zaretskii
2019-07-13 15:13                           ` Eli Zaretskii
2019-07-13 15:54                           ` Eli Zaretskii
2019-07-13 15:57                             ` Pip Cet
2019-07-13 16:02                               ` Eli Zaretskii
2019-07-13 18:17                                 ` Pip Cet
2020-08-21 12:57                                   ` Lars Ingebrigtsen
2019-07-13 15:04                         ` Andreas Politz
2019-07-12 12:44   ` Pip Cet
2019-07-12 12:55     ` Eli Zaretskii
2019-07-12 13:40       ` Pip Cet
2019-07-12 13:51         ` Eli Zaretskii
2019-07-12 14:34           ` Pip Cet
2019-07-12 15:02             ` Eli Zaretskii
2019-07-12 19:30               ` Pip Cet
2019-07-13  6:50                 ` Eli Zaretskii [this message]
2021-06-06 15:50 ` dick.r.chiang
     [not found] ` <87fsxv8182.fsf@dick>
2021-06-06 16:35   ` Eli Zaretskii
2021-06-06 19:10     ` dick.r.chiang
2021-06-06 19:27       ` Eli Zaretskii
2021-06-09 21:40         ` dick.r.chiang
2021-06-10  6:46           ` Eli Zaretskii
2021-06-10 11:52             ` dick.r.chiang
2021-06-10 14:18               ` Eli Zaretskii
2021-06-10 14:55                 ` dick.r.chiang
2021-06-10 15:04                   ` Eli Zaretskii
2021-06-10 21:36                     ` dick.r.chiang
2021-06-11  6:00                       ` Eli Zaretskii
2021-06-19 17:53                         ` Eli Zaretskii
2021-06-19 19:14                           ` dick.r.chiang
2021-06-19 19:18                             ` Eli Zaretskii
2021-06-19 21:12                               ` dick.r.chiang
2021-06-20 11:39                                 ` Eli Zaretskii
2021-06-20 14:01                                   ` dick.r.chiang
2021-06-20 15:53                                     ` Eli Zaretskii
2021-06-25 13:54                                       ` Eli Zaretskii
2021-06-10 15:35                 ` Andreas Schwab
2021-06-10 15:39                   ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83wogm1l9h.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=36609@debbugs.gnu.org \
    --cc=pipcet@gmail.com \
    --cc=politza@hochschule-trier.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).