[vlc-devel] [vlc-commits] thread: add a function to give names to threads

Steve Lhomme robux4 at ycbcr.xyz
Mon Nov 16 16:25:57 CET 2020


On 2020-11-16 15:57, Rémi Denis-Courmont wrote:
> Le lundi 16 novembre 2020, 09:31:52 EET Steve Lhomme a écrit :
>> On 2020-11-13 19:29, Rémi Denis-Courmont wrote:
>>> WTF? This was rejected by two people for multiple reasons.
>>
>> This was not rejected by two people.
> 
> Except it was.
> 
>> - Alexandre on calling pthread_setname_np because it's less code, well
>> no they all have different signatures
> 
> Except they do. The prototype is the same on Android, glibc and NetBSD (and
> likely other OSes). Not that it even needs to be exactly compatible. And so
> at least one of Alexandre's objection remains unaddressed.

If you quoted the commit that you probably didn't read, you would have 
seen this:
* Android: pthread_setname_np(pthread_self(), buf);
* NetBSD : pthread_setname_np(pthread_self(), "%s", (void*)name);
* Apple  : pthread_setname_np(name);

Linux is using the same signature as Android but they cannot be merged 
before Android requires the manually truncation to 15 chars.

>> - Alexandre on always truncating to 15, no need for extra string
>> manipulation when we don't need to
> 
> As Alexandre already pointed out, that's irrelevant.

Doing more code is useless. That's wrong to forward the limitations of 
Android to all other Linux systems. I stand with what I already said.

>> - saying Android specific code is not specific to Android, contrary to
>> what currently exists in master and what the latest Google code does and
>> document (they don't truncate and reject anything bigger than 15, unlike
>> Linux)
> 
> I also point out missing cast, failing to avoid ifdefs, and bypassing glibc.

The cast would be better indeed.

What missing ifdef ? Every call is different. Read the code.

You never mentioned bypassing glibc as a reason to do differently. But 
that may a valid reason. What is the benefit of this ?

> And no, dav1d is NOT a valid rationale

At least they can read code.


More information about the vlc-devel mailing list