bug#32501: Bouncing parentheses broken in REPL with vi-mode enabled

[Mark H Weaver]

Hi again,

> Daniel Tam  writes:
>
>> I've activated readline support for the Guile repl, but I've found that
>> if my inputrc enables vi-mode, then the bouncing parentheses feature
>> doesn't work. Disabling vi-mode does the trick.
>
> Indeed.  For some reason that I cannot determine, the bouncing
> parentheses feature is specifically disabled when the vi keymap is in
> use.

I think I now see the reason for it.  I noticed that readline's default
vi keymap includes a binding for '%', which jumps to the paren matching
the one under the cursor.  That reminded me, from many years ago when I
used vi more often, that this is the way that old vi traditionally
allows matching parens to be found.

So, I guess the decision long ago to disable bouncing parens when in vi
mode was to match the way that emacs and vi behaved at that time.

However, I just tried modern vim, and I see that it now highlights
matching parens by default.  So, we should probably remove the 'if' to
match this newer behavior.

   Mark

bug#32501: Bouncing parentheses broken in REPL with vi-mode enabled

[Mark H Weaver]

Hi Daniel,

Daniel Tam  writes:

> I've activated readline support for the Guile repl, but I've found that
> if my inputrc enables vi-mode, then the bouncing parentheses feature
> doesn't work. Disabling vi-mode does the trick.

Indeed.  For some reason that I cannot determine, the bouncing
parentheses feature is specifically disabled when the vi keymap is in
use.  The relevant function is 'init_bouncing_parens' in
guile-readline/readline.c:

  static void
  init_bouncing_parens ()
  {
if (strncmp (rl_get_keymap_name (rl_get_keymap ()), "vi", 2))
  {
rl_bind_key (')', match_paren);
rl_bind_key (']', match_paren);
rl_bind_key ('}', match_paren);
  }
  }

This is ancient code, predating version control, present in the original
import into CVS in 1999.

I looked at the source code of readline-7.0, and IIUC none of those keys
have mappings in the default vi keymap.

The right fix might be to simply remove the 'if' check above.  Would you
like to try it and report back?

  Thanks,
Mark

bug#31878: Module autoloading is not thread safe

[Mark H Weaver]

I wrote:

> I thought about how to fix this thread-safety problem a long time ago,
> and came up with a rough outline of a solution.  The idea is that the
> module should not be added to the global module table until the module
> has finished loading.  While the module is being loaded, it would be
> made visible only to the loading thread, and to any other threads
> spawned during the loading process, by adding the module to a local list
> of modules-being-loaded referenced by a fluid variable.  If any other
> threads attempt to access the module, it would not be found in the
> global module table, and thus trigger an auto-load, which would wait for
> the lock to be released before proceeding.

I forgot to mention an important aspect of the proposed auto-load
locking here.  It would not be a global lock, but rather a lock specific
to the module being loaded.  So, I guess we would need a global table of
locks for modules-being-loaded.

Since Guile (unfortunately) allows cyclic module dependencies, we would
need a mechanism to avoid deadlocks in case modules A and B both import
each other, and two threads concurrently attempt to load those modules.

The first idea that comes to mind is to also have a global structure
storing a partial order on the modules currently being loaded.  If,
while module A is being loaded, there's an attempt to auto-load module
B, then an entry (A < B) would added to the partial order.  The partial
order would not allow cycles to be introduced, reporting an error in
that case.  In case a cycle would be introduced when adding (A < B),
then the thread would simply be given access to the partially-loaded
module B, by adding B to its local list of modules-being-loaded.

Comments and suggestions welcome,

Mark

bug#32367: 2.2.4 hangs when a script uses a module that calls sigaction

[Mark H Weaver]

Hi Derek,

Derek Upham  writes:

> Thanks.  I built from 4c91de3e4 and was able to reproduce the problem.
> Then I reverted 761cf0fb8c364e885e4c6fced34563f8157c3b84 and I was not
> able to reproduce it.

Thanks for checking.  I've reopened  which
led to the faulty commit, and sent some messages there proposing a rough
outline for a more proper fix.

  Mark

bug#31878: Module autoloading is not thread safe

[Mark H Weaver]

Hi Ludovic,

l...@gnu.org (Ludovic Courtès) writes:

> l...@gnu.org (Ludovic Courtès) skribis:
>
>> l...@gnu.org (Ludovic Courtès) skribis:
>>
>>> I believe this comes from the fact that ‘autoloads-done’ and related
>>> alists in (ice-9 boot-9) are manipulated in a non-thread-safe fashion.
>>
>> Here’s a proposed fix for ‘stable-2.2’ as discussed on #guile, Andy:
>
> After further discussion on IRC, I pushed a variant of this patch as
> commit 761cf0fb8c364e885e4c6fced34563f8157c3b84.

There are problems with this fix, e.g. .

More generally, nearly arbitrary code can be run in the top-level
expressions of a module.  It could launch other threads which try to
load modules, or even send messages to other existing threads asking
them to do work.  In some cases, the body of the module might never
terminate.  The entire main program might be run from there.  I suspect
that's not unusual.

I can see another problem as well: while the module is in the process of
loading, the partially-loaded module is globally visible and accessible
to other threads.  If I'm not mistaken, with this patch, there's nothing
preventing other threads from attempting to use the partially-loaded
module.

I thought about how to fix this thread-safety problem a long time ago,
and came up with a rough outline of a solution.  The idea is that the
module should not be added to the global module table until the module
has finished loading.  While the module is being loaded, it would be
made visible only to the loading thread, and to any other threads
spawned during the loading process, by adding the module to a local list
of modules-being-loaded referenced by a fluid variable.  If any other
threads attempt to access the module, it would not be found in the
global module table, and thus trigger an auto-load, which would wait for
the lock to be released before proceeding.

What do you think?

  Mark

bug#32501: Bouncing parentheses broken in REPL with vi-mode enabled

[Daniel Tam]

Hi,


I've activated readline support for the Guile repl, but I've found that
if my inputrc enables vi-mode, then the bouncing parentheses feature
doesn't work. Disabling vi-mode does the trick.


Cheers,

Dan

bug#32367: 2.2.4 hangs when a script uses a module that calls sigaction

[Derek Upham]

Thanks.  I built from 4c91de3e4 and was able to reproduce the problem.  Then I 
reverted 761cf0fb8c364e885e4c6fced34563f8157c3b84 and I was not able to 
reproduce it.

So it’s probably the signal delivery thread starting in that module, and trying 
to load another module immediately.  This isn’t the first time the signal 
delivery thread has exposed an issue: 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26858

Derek

Mark H Weaver  writes:

> I don't have time now for a proper investigation, but this might be
> related to commit 761cf0fb8c364e885e4c6fced34563f8157c3b84 (Make module
> autoloading thread-safe).
>
>   Mark