all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Robert Pluim <rpluim@gmail.com>
Cc: 38632@debbugs.gnu.org, yantar92@gmail.com
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	[thread overview]
Message-ID: <8336dg2vvn.fsf@gnu.org> (raw)
In-Reply-To: <m2sglh5nkp.fsf@gmail.com> (message from Robert Pluim on Wed, 18 Dec 2019 22:30:14 +0100)

> 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	other threads:[~2019-12-19 15:11 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-16  6:42 bug#38632: 27.0.50; Emacs process name is changed permanently upon creating a named thread Ihor Radchenko
2019-12-17 20:05 ` Eli Zaretskii
2019-12-18  9:05   ` Robert Pluim
2019-12-18 15:53     ` Eli Zaretskii
2019-12-18 17:04       ` Robert Pluim
2019-12-18 17:18         ` Eli Zaretskii
2019-12-18 21:30           ` Robert Pluim
2019-12-19 15:11             ` Eli Zaretskii [this message]
2019-12-19 16:42               ` Robert Pluim
2019-12-19 18:56                 ` Eli Zaretskii
2019-12-20 19:13               ` Eli Zaretskii
2020-01-06 14:43                 ` Robert Pluim
2020-01-06 16:22                   ` Eli Zaretskii
2020-01-06 19:50 ` Mattias Engdegård
2020-01-06 21:58   ` Mattias Engdegård
2020-01-06 23:06     ` Robert Pluim
2020-01-07 15:45     ` Eli Zaretskii
2020-01-07 16:46       ` Mattias Engdegård
2020-01-07 17:05         ` Eli Zaretskii
2020-01-07 17:07         ` Eli Zaretskii
2020-01-07 17:19           ` Mattias Engdegård
2020-01-08 18:26         ` Glenn Morris
2020-01-08 18:54           ` Eli Zaretskii
2020-01-08 19:34             ` Glenn Morris
2020-01-08 20:01               ` Eli Zaretskii
2020-01-06 22:21   ` Robert Pluim

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8336dg2vvn.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=38632@debbugs.gnu.org \
    --cc=rpluim@gmail.com \
    --cc=yantar92@gmail.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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.