From: Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gerd.moellmann@gmail.com, ofv@wanadoo.es, emacs-devel@gnu.org,
eller.helmut@gmail.com, acorallo@gnu.org
Subject: Re: Some experience with the igc branch
Date: Mon, 23 Dec 2024 17:16:32 +0000 [thread overview]
Message-ID: <87cyhicocg.fsf@protonmail.com> (raw)
In-Reply-To: <86bjx24ad0.fsf@gnu.org>
"Eli Zaretskii" <eliz@gnu.org> writes:
>> Date: Mon, 23 Dec 2024 16:03:53 +0000
>> From: Pip Cet <pipcet@protonmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org
>>
>> --- a/src/igc.c
>> +++ b/src/igc.c
>> @@ -747,19 +747,41 @@ IGC_DEFINE_LIST (igc_root);
>>
>> /* Registry entry for an MPS thread mps_thr_t. */
>>
>> +#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?
>> +struct emacs_ap
>> +{
>> + mps_ap_t mps_ap;
>> + struct igc *gc;
>> + pthread_t allocation_thread;
>
> pthread_t is non-portable, for the same reasons.
>
>> This is the "slow path" only, used for all allocations. Will cause a
>> great number of busy-looping threads.
>
> A lot of threads might be problematic. Each thread reserves memory
> for its stack, so you end up with lots of reserved memory, and on
> 32-bit systems can run out of address space.
This is a PoC. While we shouldn't share structures between Emacs-side
threads, we should of course use (at most) a single allocation thread
rather than one per thread per AP. Also, yield the CPU once in a while
:-)
> 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.
Pip
next prev parent reply other threads:[~2024-12-23 17:16 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-22 15:40 Some experience with the igc branch Óscar Fuentes
2024-12-22 17:18 ` Gerd Möllmann
2024-12-22 17:29 ` Gerd Möllmann
2024-12-22 17:41 ` Pip Cet via Emacs development discussions.
2024-12-22 17:56 ` Gerd Möllmann
2024-12-22 19:11 ` Óscar Fuentes
2024-12-23 0:05 ` Pip Cet via Emacs development discussions.
2024-12-23 1:00 ` Óscar Fuentes
2024-12-23 3:42 ` Gerd Möllmann
2024-12-23 6:27 ` Jean Louis
2024-12-22 20:29 ` Helmut Eller
2024-12-22 20:50 ` Gerd Möllmann
2024-12-22 22:26 ` Pip Cet via Emacs development discussions.
2024-12-23 3:23 ` Gerd Möllmann
[not found] ` <m234ieddeu.fsf_-_@gmail.com>
[not found] ` <87ttaueqp9.fsf@protonmail.com>
[not found] ` <m2frme921u.fsf@gmail.com>
[not found] ` <87ldw6ejkv.fsf@protonmail.com>
[not found] ` <m2bjx2h8dh.fsf@gmail.com>
2024-12-23 14:45 ` Make Signal handling patch platform-dependent? Pip Cet via Emacs development discussions.
2024-12-23 14:54 ` Gerd Möllmann
2024-12-23 15:11 ` Eli Zaretskii
2024-12-23 13:35 ` Some experience with the igc branch Eli Zaretskii
2024-12-23 14:03 ` Discussion with MPS people Gerd Möllmann
2024-12-23 14:04 ` Gerd Möllmann
2024-12-23 15:07 ` Some experience with the igc branch Pip Cet via Emacs development discussions.
2024-12-23 15:26 ` Gerd Möllmann
2024-12-23 16:03 ` Pip Cet via Emacs development discussions.
2024-12-23 16:44 ` Eli Zaretskii
2024-12-23 17:16 ` Pip Cet via Emacs development discussions. [this message]
2024-12-23 18:35 ` Eli Zaretskii
2024-12-23 18:48 ` Gerd Möllmann
2024-12-23 19:25 ` Eli Zaretskii
2024-12-23 20:30 ` Benjamin Riefenstahl
2024-12-23 17:44 ` Gerd Möllmann
2024-12-23 19:00 ` Eli Zaretskii
2024-12-23 19:37 ` Eli Zaretskii
2024-12-23 20:49 ` Gerd Möllmann
2024-12-23 21:43 ` Helmut Eller
[not found] ` <87r05yax5a.fsf@protonmail.com>
2024-12-23 21:58 ` Helmut Eller
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=87cyhicocg.fsf@protonmail.com \
--to=emacs-devel@gnu.org \
--cc=acorallo@gnu.org \
--cc=eliz@gnu.org \
--cc=eller.helmut@gmail.com \
--cc=gerd.moellmann@gmail.com \
--cc=ofv@wanadoo.es \
--cc=pipcet@protonmail.com \
/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).