emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some experience with the igc branch


From: Eli Zaretskii
Subject: Re: Some experience with the igc branch
Date: Mon, 23 Dec 2024 20:35:21 +0200

> Date: Mon, 23 Dec 2024 17:16:32 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: gerd.moellmann@gmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, 
> eller.helmut@gmail.com, acorallo@gnu.org
> 
> "Eli Zaretskii" <eliz@gnu.org> writes:
> 
> >> +#include <pthread.h>
> >
> > We cannot use pthreads.h in portable code.  If we want to use threads,
> > we need separate implementations for Posix and Windows, like wedid in
> > systhread.c for Lisp threads.
> 
> Noted.
> 
> As an aside, without any relevance to the fact that we should avoid
> using them, aren't pthreads available on "mingw"64 systems?

pthreads are ported to both 32-bit and 64-bit Windows (more than
once), but the ports are buggy, and pthreads.h itself defines all
kinds of stuff that conflicts with various w32 places in Emacs.  The
following lines from nt/mingw-site.cfg is one sign of that:

  # We don't want pthread.h to be picked up just because it defines timespec
  gl_cv_sys_struct_timespec_in_pthread_h=no
  # Or at all...
  ac_cv_header_pthread_h=no

> > Why do we need this, again?
> 
> We can't interrupt allocation, so we move it to a separate thread where
> it will complete (unlocking the arena) even if a signal interrupts us.

How will this allow us to run the Lisp machine from a signal?  Because
this is the goal, right?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]