This is the mail archive of the libc-help@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: losing events with EPOLLONESHOT and cancellation


Ãngel GonzÃlez <keisial@gmail.com> wrote:
> On 12/06/13 18:56, Eric Wong wrote:
> >Thanks.  With pthread_cleanup_*, I can't see the return value of the
> >cancelled syscall.  So I think my alternative is to not rely on normal
> >syscalls being cancellable and explicitly put cancellation points in my
> >program around interruptible syscalls, using pthread_kill in a loop in
> >addition to pthread_cancel.

> If you need to explicitely mark like that the points where you want
> to accept
> cancellation, I would probably find clearer a if (cancel_thread2)
> pthread_exit();
> 
> (and instead of pthread_cancel(thread_2); you would set to true the volatile
> cancel_thread2 variable). But that should be equivalent. If you prefer that way,
> it's up to the programmer.

Good point, I'm doing that.  I'm not sure about volatile, though[1].
I'm just using the gcc/clang __sync_add_and_fetch(&do_quit, (0|1))
to check/increment: http://bogomips.org/cmogstored.git/patch/?id=f42f8d14

[1] based on my reading of volatile-considered-harmful.txt in Linux
    kernel docs, but I think that applies to userspace, too.

> Also note that you probably want to continue the for in the EINTR case, so you
> don't need to copy the pthread_setcancelstate(), as continuing will hit them.

Since all the accept/epoll_wait calls are already in a loop, I only put
the quit check before entering the waiting syscalls to reduce code size.


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