GNU bug report logs - #72689
31.0.50; Proposal to improve string-pixel-width

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: David Ponce <da_vid <at> orange.fr>
Cc: 72689 <at> debbugs.gnu.org
Subject: bug#72689: 31.0.50; Proposal to improve string-pixel-width
Date: Wed, 21 Aug 2024 16:17:12 +0300

> Date: Tue, 20 Aug 2024 17:12:45 +0200
> Cc: 72689 <at> debbugs.gnu.org
> From: David Ponce <da_vid <at> orange.fr>
> 
> On 18/08/2024 11:15 AM, Eli Zaretskii wrote:
> [...]
> >>> Thanks.  The idea SGTM, but I think the implementation needs to cater
> >>> for the case where more than one execution thread performs this job
> >>> "in parallel" (however improbable this could sound), so we need to be
> >>> able to detect when this buffer is "busy".  The simplest way is to use
> >>> some boolean buffer-local variable, which will be set non-nil when the
> >>> function starts using the buffer and reset to nil when the function is
> >>> done with its job.
> 
> I've been thinking more about the parallelism issue when a function
> reuses a temporary buffer for its activity, and I wonder if we could
> use a simple API like the one below to safely get an exclusive working
> buffer without having to create a new one on each call?

Thanks, but using a mutex is overkill: there could be no race between
two or more threads in this case in accessing the buffer-local
variable, because only one Lisp thread can be running at any given
time.  So the simpler method of testing the "busy" flag should be
sufficient.

> Compared to my previous proposal the quick benchmark above shows
> similar results for both performance and memory usage, but the new
> implementation is simpler, and the API might be useful in other
> similar cases.

Simpler implementation is OK, but I think it will be simpler yet if
you remove the mutex, which is not needed.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.