bug#30182: Update

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 03 Feb 2018 10:03:57 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: m.sujith@gmail.com, 30182@debbugs.gnu.org
> 
>  > We _cannot_ call Lisp asynchronously in any safe
>  > way.  I'm afraid we will have to roll back the change which allowed
>  > mode-line-default-help-echo to be a function.  Can you find an
>  > alternative way of achieving the same effect, that doesn't call Lisp
>  > from note_mode_line_or_margin_highlight?
> 
> I could do that easily.  But IMO the problem is not with calling Lisp
> per se.  We frequently call Lisp fnctions from C.  The problem is with
> altering the global state (`timer-list' being part of that) IIUC.
> 
>  > I think we should introduce some protection against making such
>  > implementation mistakes in the future.  Like some flag that we set
>  > when redisplay is entered asynchronously, and that is checked in
>  > safe__call, where we'd signal an error (or maybe even abort, under
>  > "--enable-checking") if the flag is set.  This should allow us to find
>  > such problems much faster.  WDYT?
> 
> I'd need to see the problem identified first.  The comment in xdisp.c
> says that
> 
>     Under window systems
>     like X, some portions of the redisplay code are also called
>     asynchronously during mouse movement or expose events.  It is very
>     important that these code parts do NOT use the C library (malloc,
>     free) because many C libraries under Unix are not reentrant.  They
>     may also NOT call functions of the Lisp interpreter which could
>     change the interpreter's state.
> 
> What is an "asynchronous call" and how can I identify it?

That commentary was outdated.  I updated it now.  Please take a look
and tell if anything there needs clarification or any other change.

I believe that what I wrote in the message to which you were replying
was based on incorrect interpretation of what actually happens.  With
the correct interpretation, there's no asynchronous entry into
redisplay, if "asynchronous" is interpreted literally.  So the
measures I described above are unnecessary, but there is a need to
block input around C fragments that cannot tolerate changes in global
state.

This now raises the question: should we block input around the 2 calls
to Fcopy_sequence in timer_check, on the emacs-26 branch?  I tend to
think we should, because letting arbitrary Lisp change the timer lists
while Fcopy_sequence runs could cause hard-to-debug bugs.  WDYT?

> And one thing that is obviously needed is some guidance on what should
> be allowed in the mode line and what should be avoided.  For example,
> having `mode-line-buffer-identification' install a timer is something
> that should be avoided IMO.

If we protect Fcopy_sequence as indicated above, I think such a
limitation would no longer be necessary.

Thanks.