Date: Wed, 2 Mar 2016 22:19:25 +0100 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: [PATCH] add sched_getcpu * Tomasz Sterna <tomek@...oka.com> [2016-03-02 21:46:53 +0100]: > W dniu 01.03.2016, wto o godzinie 17???34 -0500, u??ytkownik Rich Felker > napisa??: > > syscall(SYS_exit > > SYS_exit cannot be used safely unless you have a single-threaded > > program, and in that case you can use _exit (SYS_exit_group). > > How should I properly terminate current task then? > pthread_exit > > > syscall(SYS_gettid > > For glibc it's been controversial whether to expose tids as a public > > API, since it pokes through the pthread abstraction and imposes a 1:1 > > threads implementation. > > I am implementing a threading and mutex API that is different to > pthread. (Still 1:1 though.) > Using pthread to do this proved to be cumbersome, but using native > Linux abstractions turned out to be pretty straightforward. > that's not possible in c the semantics (memory model, libc internals..) assume that threads can only be created by the c runtime. in theory you can create you own threads, but you have to know what you are doing (no libc calls, no tls) but then you are implementing your own libc > > syscall(SYS_tgkill > > tgkill also requires tids to be exposed an potentially has other > > issues, and doesn't seem to offer anything that pthread_kill doesn't. > > As above - using pthreads is not the good way to do it in my case. > what you are doing is undefined behaviour.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.