This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add finit_module syscall for Linux

>> As you know, kill(2) has the exact same issue and pthread_kill() was naturally
>> derived from it. And we lived with kill() long time.
>> In almost all case, ID reassignment is enough strong reason to avoid
>> pthread_kill.
>> However, in several case, application have "no new thread"
>> guarantee. therefore your worst scenario can't be happen.
> The values of pthread_t are not required to be thread-local. If
> pthread_t were a kernel-level tid, the natural implementation would
> use tkill, not tgkill, which would allow signaling threads in other
> processes. There's no fundamental reason the implementation needs to
> prevent such a thing, since it's UB anyway.

Sorry, I wouldn't join which is natural. Even though I don't agree with you, we
can't persuade each other. "Natural" seems subjective argument to me.

> Neither kill nor pthread_kill have race conditions if used correctly.
> For pthread_kill, the pthread_t value is only meaningful within the
> same process, and a correctly-written application would not even
> possess the pthread_t value anymore once pthread_join has been called
> on the thread (and would not even store the pthread_t value for a
> detached thread unless it were using some other method aside from
> joining to synchronize with thread completion). Following such
> practices, any use of a pthread_t value you still have with
> pthread_kill avoids invoking UB.
> For kill, the only way to use it without races is for your own child
> processes on which you have not yet waited.

I agree application can avoid an issue if it will be rewritten.
However, I also don't
want  to join supposition and application blaming. Especially when I'm
not developer
of the applications and the fault come from historical reason. sorry.

I have several chance to know several real world application issue and
then I talk about it sometimes. However please don't think I blame
libc. I just talk about an issue, not more.
I'm ok to keep status quo. oh, say, I never say pthread_self() should
be changed.

>> more offtopic. I think current man pages is misleading.
>> >
>> >       EINVAL An invalid signal was specified.
>> >       ESRCH  No thread with the ID thread could be found.
>> I can't parse this sentence mean pthread_kill() can cause SEGV
>> if no thread could be found. I'm not surprised if people parse this as
>> pthread_kill() always return ESRCH, not crash when no such id.
> Indeed, this should be filed as a bug against the man page. In
> particular, the man page should include this text from POSIX XSH
> 2.9.2:
> "The lifetime of a thread ID ends after the thread terminates if it
> was created with the detachstate attribute set to
> PTHREAD_CREATE_DETACHED or if pthread_detach() or pthread_join() has
> been called for that thread. A conforming implementation is free to
> reuse a thread ID after its lifetime has ended. If an application
> attempts to use a thread ID whose lifetime has ended, the behavior is
> undefined."
> In particular, passing such a thread ID to pthread_kill is UB.

created an ticket of man pages.

Thank you for pointing exact paragraph.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]