bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#38632: 27.0.50; Emacs process name is changed permanently upon creat


From: Eli Zaretskii
Subject: bug#38632: 27.0.50; Emacs process name is changed permanently upon creating a named thread
Date: Thu, 19 Dec 2019 17:11:24 +0200

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 38632@debbugs.gnu.org,  yantar92@gmail.com
> Date: Wed, 18 Dec 2019 22:30:14 +0100
> 
>     >> It does exactly what you'd expect, it drops the extraneous bytes, so
>     >> putting eg ü on the boundary results in a name ending in à (#xc3).
> 
>     Eli> So it is one more reason to do or own truncation, so we do it right.
> 
> OK. Is there a useful function that would help for that? I can cook up
> something based on NEXT_CHAR_BOUNDARY and/or BYTES_BY_CHAR_HEAD, but Iʼd
> expect there to be something already.

No, the above two and their ilk (PREV_CHAR_BOUNDARY etc.) are what we
use.

>     >> In any case, if emacs or prctl truncates, then the name as reported
>     >> by 'list-threads' will be out of sync with pthread_getname_np, unless
>     >> you'd want to adjust that too.
> 
>     Eli> We need to truncate the names we store in the thread object (and
>     Eli> document that).

I think I'm going to change my mind on that.  The complication here is
that the name should be encoded by ENCODE_SYSTEM before we pass it to
pthread_setname_np etc., and if the locale-coding-system is not UTF-8
and not single-byte, we don't really know where a character will end
after encoding.  And encoding one character at a time sounds too
gross.

So perhaps we should just truncate the bytes, and leave this to the
application to make sure the result makes sense, and also disregard
the difference between list-threads and the thread name as the OS and
debuggers see it.  Doing that will also avoid the complication of
having the thread name return to the caller different from what the
caller used.

WDYT?

> Iʼm assuming mswindows doesnʼt truncate.

MS-Windows currently doesn't support setting thread names at all;
maybe I'll write something soon to fix that.  But yes, I cannot find
any documentation stating any limits there.  GDB on Windows reads the
first 1024 bytes of the thread name, so maybe we should document that
this is the recommended maximum on any platform.

Thanks.





reply via email to

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