From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9442 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] add sched_getcpu Date: Wed, 2 Mar 2016 22:19:25 +0100 Message-ID: <20160302211924.GI29662@port70.net> References: <1456764572-18648-1-git-send-email-nathan@nathan7.eu> <1456780194.12169.25.camel@xiaoka.com> <20160229213057.GE9349@brightrain.aerifal.cx> <1456864521.12169.35.camel@xiaoka.com> <20160301223419.GL9349@brightrain.aerifal.cx> <1456951613.12169.42.camel@xiaoka.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1456953580 10440 80.91.229.3 (2 Mar 2016 21:19:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Mar 2016 21:19:40 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9455-gllmg-musl=m.gmane.org@lists.openwall.com Wed Mar 02 22:19:39 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1abEBH-0004f7-9i for gllmg-musl@m.gmane.org; Wed, 02 Mar 2016 22:19:39 +0100 Original-Received: (qmail 3789 invoked by uid 550); 2 Mar 2016 21:19:37 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 3763 invoked from network); 2 Mar 2016 21:19:36 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <1456951613.12169.42.camel@xiaoka.com> User-Agent: Mutt/1.5.24 (2015-08-30) Xref: news.gmane.org gmane.linux.lib.musl.general:9442 Archived-At: * Tomasz Sterna [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.