This is the mail archive of the libc-alpha@sourceware.org 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


On Fri, Jan 25, 2013 at 05:20:22PM -0500, KOSAKI Motohiro wrote:
> >> I have no idea how to return -ESRCH if using pointer. Do you have?
> >
> > there's no requirement to do so; in fact, doing so is harmful because
> > the code may seem to work (kill failing) but then signal the wrong
> > thread if the same tid got reassigned to a new thread. any use of a
> > pthtead_t after its lifetime is a serious programming error that is
> > fundamentally undetectable, just like using a pointer to malloc'd
> > memory after it was freed or using a pid aftef it was waited on.
> 
> Even though some one says "it's no requirement". Such applications don't
> vanish.

I don't see any reason to believe such applications exist. Even if
they do, they're already very unreliable, it's not doing anyone a
service to make these applications appear to work correctly 99% of the
time and crash the other 1% of the time. It just leads to serious bugs
going undetected. Even if the implementation does "detect" use a
pthread_t whose lifetime has ended (e.g. by its presence in the cache
of stacks for reuse), the proper behavior is to call abort() or
otherwise crash, not to return ESRCH. Aborting is legal (conforming)
because the application has invoked undefined behavior (by using a
pthread_t whose lifetime has ended).

> I agree id reassignment issue can be happen. however it doesn't
> bring any happy to applications.
> 
> But anyway this is highly off topic. I have to stop hijack the thread.

It may be mildly off-topic for the thread, but I think it's on-topic
for this list in general.

Rich


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