<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
	<id>tag:old.nabble.com,2006:forum-6629</id>
	<title>Nabble - freebsd-threads</title>
	<updated>2009-12-01T12:08:42Z</updated>
	<link rel="self" type="application/atom+xml" href="http://old.nabble.com/freebsd-threads-f6629.xml" />
	<link rel="alternate" type="text/html" href="http://old.nabble.com/freebsd-threads-f6629.html" />
	<subtitle type="html">Threading on FreeBSD</subtitle>
	
<entry>
	<id>tag:old.nabble.com,2006:post-26598276</id>
	<title>Re: junk/141071: drvrouph</title>
	<published>2009-12-01T12:08:42Z</published>
	<updated>2009-12-01T12:08:42Z</updated>
	<author>
		<name>linimon</name>
	</author>
	<content type="html">Synopsis: drvrouph
&lt;br&gt;&lt;br&gt;State-Changed-From-To: open-&amp;gt;closed
&lt;br&gt;State-Changed-By: linimon
&lt;br&gt;State-Changed-When: Tue Dec 1 20:08:08 UTC 2009
&lt;br&gt;State-Changed-Why: 
&lt;br&gt;spam
&lt;br&gt;&lt;br&gt;&lt;a href=&quot;http://www.freebsd.org/cgi/query-pr.cgi?pr=141071&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.freebsd.org/cgi/query-pr.cgi?pr=141071&lt;/a&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26598276&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads@...&lt;/a&gt; mailing list
&lt;br&gt;&lt;a href=&quot;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&lt;/a&gt;&lt;br&gt;To unsubscribe, send any mail to &amp;quot;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26598276&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads-unsubscribe@...&lt;/a&gt;&amp;quot;
&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Re%3A-junk-141071%3A-drvrouph-tp26598276p26598276.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26598233</id>
	<title>Re: junk/141062: wijlbewt</title>
	<published>2009-12-01T12:05:13Z</published>
	<updated>2009-12-01T12:05:13Z</updated>
	<author>
		<name>linimon</name>
	</author>
	<content type="html">Synopsis: wijlbewt
&lt;br&gt;&lt;br&gt;State-Changed-From-To: open-&amp;gt;closed
&lt;br&gt;State-Changed-By: linimon
&lt;br&gt;State-Changed-When: Tue Dec 1 20:04:24 UTC 2009
&lt;br&gt;State-Changed-Why: 
&lt;br&gt;spam
&lt;br&gt;&lt;br&gt;&lt;br&gt;Responsible-Changed-From-To: freebsd-threads-&amp;gt;gnats-adm
&lt;br&gt;Responsible-Changed-By: linimon
&lt;br&gt;Responsible-Changed-When: Tue Dec 1 20:04:24 UTC 2009
&lt;br&gt;Responsible-Changed-Why: 
&lt;br&gt;&lt;br&gt;&lt;a href=&quot;http://www.freebsd.org/cgi/query-pr.cgi?pr=141062&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.freebsd.org/cgi/query-pr.cgi?pr=141062&lt;/a&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26598233&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads@...&lt;/a&gt; mailing list
&lt;br&gt;&lt;a href=&quot;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&lt;/a&gt;&lt;br&gt;To unsubscribe, send any mail to &amp;quot;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26598233&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads-unsubscribe@...&lt;/a&gt;&amp;quot;
&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Re%3A-junk-141062%3A-wijlbewt-tp26598233p26598233.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26596913</id>
	<title>threads/141071: drvrouph</title>
	<published>2009-12-01T10:35:43Z</published>
	<updated>2009-12-01T10:35:43Z</updated>
	<author>
		<name>drvrouph</name>
	</author>
	<content type="html">&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt;Number: &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; 141071
&lt;br&gt;&amp;gt;Category: &amp;nbsp; &amp;nbsp; &amp;nbsp; threads
&lt;br&gt;&amp;gt;Synopsis: &amp;nbsp; &amp;nbsp; &amp;nbsp; drvrouph
&lt;br&gt;&amp;gt;Confidential: &amp;nbsp; no
&lt;br&gt;&amp;gt;Severity: &amp;nbsp; &amp;nbsp; &amp;nbsp; critical
&lt;br&gt;&amp;gt;Priority: &amp;nbsp; &amp;nbsp; &amp;nbsp; high
&lt;br&gt;&amp;gt;Responsible: &amp;nbsp; &amp;nbsp;freebsd-threads
&lt;br&gt;&amp;gt;State: &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;open
&lt;br&gt;&amp;gt;Quarter: &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;
&lt;br&gt;&amp;gt;Keywords: &amp;nbsp; &amp;nbsp; &amp;nbsp; 
&lt;br&gt;&amp;gt;Date-Required:
&lt;br&gt;&amp;gt;Class: &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;change-request
&lt;br&gt;&amp;gt;Submitter-Id: &amp;nbsp; current-users
&lt;br&gt;&amp;gt;Arrival-Date: &amp;nbsp; Tue Dec 01 18:40:04 UTC 2009
&lt;br&gt;&amp;gt;Closed-Date:
&lt;br&gt;&amp;gt;Last-Modified:
&lt;br&gt;&amp;gt;Originator: &amp;nbsp; &amp;nbsp; drvrouph
&lt;br&gt;&amp;gt;Release: &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;drvrouph
&lt;br&gt;&amp;gt;Organization:
&lt;/div&gt;drvrouph
&lt;br&gt;&amp;gt;Environment:
&lt;br&gt;drvrouph
&lt;br&gt;&amp;gt;Description:
&lt;br&gt;qednihrj &lt;a href=&quot;http://bpoikifz.com&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://bpoikifz.com&lt;/a&gt;&amp;nbsp;opipimca rtsgnyou
&lt;br&gt;&amp;gt;How-To-Repeat:
&lt;br&gt;drvrouph
&lt;br&gt;&amp;gt;Fix:
&lt;br&gt;drvrouph
&lt;br&gt;&lt;br&gt;&amp;gt;Release-Note:
&lt;br&gt;&amp;gt;Audit-Trail:
&lt;br&gt;&amp;gt;Unformatted:
&lt;br&gt;_______________________________________________
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26596913&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads@...&lt;/a&gt; mailing list
&lt;br&gt;&lt;a href=&quot;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&lt;/a&gt;&lt;br&gt;To unsubscribe, send any mail to &amp;quot;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26596913&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads-unsubscribe@...&lt;/a&gt;&amp;quot;
&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/threads-141071%3A-drvrouph-tp26596913p26596913.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26596895</id>
	<title>threads/141062: wijlbewt</title>
	<published>2009-12-01T10:31:36Z</published>
	<updated>2009-12-01T10:31:36Z</updated>
	<author>
		<name>wijlbewt</name>
	</author>
	<content type="html">&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt;Number: &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; 141062
&lt;br&gt;&amp;gt;Category: &amp;nbsp; &amp;nbsp; &amp;nbsp; threads
&lt;br&gt;&amp;gt;Synopsis: &amp;nbsp; &amp;nbsp; &amp;nbsp; wijlbewt
&lt;br&gt;&amp;gt;Confidential: &amp;nbsp; no
&lt;br&gt;&amp;gt;Severity: &amp;nbsp; &amp;nbsp; &amp;nbsp; critical
&lt;br&gt;&amp;gt;Priority: &amp;nbsp; &amp;nbsp; &amp;nbsp; medium
&lt;br&gt;&amp;gt;Responsible: &amp;nbsp; &amp;nbsp;freebsd-threads
&lt;br&gt;&amp;gt;State: &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;open
&lt;br&gt;&amp;gt;Quarter: &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;
&lt;br&gt;&amp;gt;Keywords: &amp;nbsp; &amp;nbsp; &amp;nbsp; 
&lt;br&gt;&amp;gt;Date-Required:
&lt;br&gt;&amp;gt;Class: &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;sw-bug
&lt;br&gt;&amp;gt;Submitter-Id: &amp;nbsp; current-users
&lt;br&gt;&amp;gt;Arrival-Date: &amp;nbsp; Tue Dec 01 18:40:01 UTC 2009
&lt;br&gt;&amp;gt;Closed-Date:
&lt;br&gt;&amp;gt;Last-Modified:
&lt;br&gt;&amp;gt;Originator: &amp;nbsp; &amp;nbsp; wijlbewt
&lt;br&gt;&amp;gt;Release: &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;wijlbewt
&lt;br&gt;&amp;gt;Organization:
&lt;/div&gt;wijlbewt
&lt;br&gt;&amp;gt;Environment:
&lt;br&gt;wijlbewt
&lt;br&gt;&amp;gt;Description:
&lt;br&gt;&amp;nbsp;[URL=&lt;a href=&quot;http://kaulsjhz.com&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://kaulsjhz.com&lt;/a&gt;]xcbnyrox[/URL] &amp;nbsp;&amp;lt;a href=&amp;quot;&lt;a href=&quot;http://lqiziqmx.com&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lqiziqmx.com&lt;/a&gt;&amp;quot;&amp;gt;uhwpnrsy&amp;lt;/a&amp;gt; &amp;nbsp;qkaajlab &lt;a href=&quot;http://dhgckxlu.com&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://dhgckxlu.com&lt;/a&gt;&amp;nbsp;tpzoscmf ijbgoyzc 
&lt;br&gt;&amp;gt;How-To-Repeat:
&lt;br&gt;wijlbewt
&lt;br&gt;&amp;gt;Fix:
&lt;br&gt;wijlbewt
&lt;br&gt;&lt;br&gt;&amp;gt;Release-Note:
&lt;br&gt;&amp;gt;Audit-Trail:
&lt;br&gt;&amp;gt;Unformatted:
&lt;br&gt;_______________________________________________
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26596895&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads@...&lt;/a&gt; mailing list
&lt;br&gt;&lt;a href=&quot;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&lt;/a&gt;&lt;br&gt;To unsubscribe, send any mail to &amp;quot;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26596895&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads-unsubscribe@...&lt;/a&gt;&amp;quot;
&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/threads-141062%3A-wijlbewt-tp26596895p26596895.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26572985</id>
	<title>Current problem reports assigned to freebsd-threads@FreeBSD.org</title>
	<published>2009-11-30T03:07:02Z</published>
	<updated>2009-11-30T03:07:02Z</updated>
	<author>
		<name>FreeBSD bugmaster</name>
	</author>
	<content type="html">Note: to view an individual PR, use:
&lt;br&gt;&amp;nbsp; &lt;a href=&quot;http://www.freebsd.org/cgi/query-pr.cgi?pr=(number&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.freebsd.org/cgi/query-pr.cgi?pr=(number&lt;/a&gt;).
&lt;br&gt;&lt;br&gt;The following is a listing of current problems submitted by FreeBSD users.
&lt;br&gt;These represent problem reports covering all versions including
&lt;br&gt;experimental development code and obsolete releases.
&lt;br&gt;&lt;br&gt;&lt;br&gt;S Tracker &amp;nbsp; &amp;nbsp; &amp;nbsp;Resp. &amp;nbsp; &amp;nbsp; &amp;nbsp;Description
&lt;br&gt;--------------------------------------------------------------------------------
&lt;br&gt;o threa/136345 threads &amp;nbsp; &amp;nbsp;Recursive read rwlocks in thread A cause deadlock with
&lt;br&gt;o threa/135673 threads &amp;nbsp; &amp;nbsp;databases/mysql50-server - MySQL query lock-ups on 7.2
&lt;br&gt;p threa/135462 threads &amp;nbsp; &amp;nbsp;[PATCH] _thread_cleanupspecific() doesn't handle delet
&lt;br&gt;o threa/133734 threads &amp;nbsp; &amp;nbsp;32 bit libthr failing pthread_create()
&lt;br&gt;o threa/128922 threads &amp;nbsp; &amp;nbsp;threads hang with xorg running
&lt;br&gt;o threa/127225 threads &amp;nbsp; &amp;nbsp;bug in lib/libthr/thread/thr_init.c
&lt;br&gt;o threa/122923 threads &amp;nbsp; &amp;nbsp;'nice' does not prevent background process from steali
&lt;br&gt;o threa/121336 threads &amp;nbsp; &amp;nbsp;lang/neko threading ok on UP, broken on SMP (FreeBSD 7
&lt;br&gt;o threa/118715 threads &amp;nbsp; &amp;nbsp;kse problem
&lt;br&gt;o threa/116668 threads &amp;nbsp; &amp;nbsp;can no longer use jdk15 with libthr on -stable SMP
&lt;br&gt;o threa/116181 threads &amp;nbsp; &amp;nbsp;/dev/io-related io access permissions are not propagat
&lt;br&gt;o threa/115211 threads &amp;nbsp; &amp;nbsp;pthread_atfork misbehaves in initial thread
&lt;br&gt;o threa/110636 threads &amp;nbsp; &amp;nbsp;[request] gdb(1): using gdb with multi thread applicat
&lt;br&gt;o threa/110306 threads &amp;nbsp; &amp;nbsp;apache 2.0 segmentation violation when calling gethost
&lt;br&gt;o threa/103975 threads &amp;nbsp; &amp;nbsp;Implicit loading/unloading of libpthread.so may crash 
&lt;br&gt;o threa/101323 threads &amp;nbsp; &amp;nbsp;[patch] fork(2) in threaded programs broken.
&lt;br&gt;s threa/100815 threads &amp;nbsp; &amp;nbsp;FBSD 5.5 broke nanosleep in libc_r
&lt;br&gt;s threa/94467 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;send(), sendto() and sendmsg() are not correct in libc
&lt;br&gt;s threa/84483 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;problems with devel/nspr and -lc_r on 4.x
&lt;br&gt;o threa/83914 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;[libc] popen() doesn't work in static threaded program
&lt;br&gt;o threa/80992 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;abort() sometimes not caught by gdb depending on threa
&lt;br&gt;o threa/80435 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;panic on high loads
&lt;br&gt;o threa/79887 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;[patch] freopen() isn't thread-safe
&lt;br&gt;o threa/79683 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;svctcp_create() fails if multiple threads call at the 
&lt;br&gt;s threa/76694 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;fork cause hang in dup()/close() function in child (-l
&lt;br&gt;s threa/76690 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;fork hang in child for -lc_r
&lt;br&gt;o threa/75374 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;pthread_kill() ignores SA_SIGINFO flag
&lt;br&gt;o threa/75273 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;FBSD 5.3 &amp;nbsp;libpthread (KSE) bug
&lt;br&gt;o threa/72953 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST
&lt;br&gt;o threa/70975 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;[sysvipc] unexpected and unreliable behaviour when usi
&lt;br&gt;s threa/69020 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;pthreads library leaks _gc_mutex
&lt;br&gt;s threa/49087 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;Signals lost in programs linked with libc_r
&lt;br&gt;s threa/48856 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;Setting SIGCHLD to SIG_IGN still leaves zombies under 
&lt;br&gt;s threa/40671 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;pthread_cancel doesn't remove thread from condition qu
&lt;br&gt;s threa/39922 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;[threads] [patch] Threaded applications executed with 
&lt;br&gt;s threa/37676 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra
&lt;br&gt;s threa/34536 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;accept() blocks other threads
&lt;br&gt;s threa/32295 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;[libc_r] [patch] pthread(3) dont dequeue signals
&lt;br&gt;s threa/30464 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;pthread mutex attributes -- pshared
&lt;br&gt;s threa/24632 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;libc_r delicate deviation from libc in handling SIGCHL
&lt;br&gt;s threa/24472 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o
&lt;br&gt;&lt;br&gt;41 problems total.
&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26572985&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads@...&lt;/a&gt; mailing list
&lt;br&gt;&lt;a href=&quot;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&lt;/a&gt;&lt;br&gt;To unsubscribe, send any mail to &amp;quot;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26572985&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads-unsubscribe@...&lt;/a&gt;&amp;quot;
&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Current-problem-reports-assigned-to-freebsd-threads%40FreeBSD.org-tp26572985p26572985.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26548815</id>
	<title>Re: [PATCH] Add missing pthread_condattr_{init, destroy} stubs to libc</title>
	<published>2009-11-27T14:50:24Z</published>
	<updated>2009-11-27T14:50:24Z</updated>
	<author>
		<name>Daniel Eischen-2</name>
	</author>
	<content type="html">On Nov 27, 2009, at 4:47 PM, Joe Marcus Clarke &amp;lt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26548815&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;marcus@...&lt;/a&gt;&amp;gt; &amp;nbsp;
&lt;br&gt;wrote:
&lt;br&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; On Fri, 2009-11-27 at 16:19 -0500, Daniel Eischen wrote:
&lt;br&gt;&amp;gt;&amp;gt; On Nov 27, 2009, at 2:14 PM, Joe Marcus Clarke &amp;lt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26548815&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;marcus@...&lt;/a&gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; wrote:
&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; On Fri, 2009-11-27 at 15:12 +0200, Kostik Belousov wrote:
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; On Fri, Nov 27, 2009 at 12:15:18AM -0500, Joe Marcus Clarke wrote:
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; I would like permission to commit this patch which adds missing
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; pthread_condattr_{init,destroy} symbols to libc. &amp;nbsp;I think I did &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; the
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; symbol addition correctly (and it seems to work). &amp;nbsp;Without this, &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; the
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; weak symbols added in the libpthread-stubs port conflict with
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; those in
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; libthr, and applications with use these symbols can crash.
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; I have temporarily hacked libpthread-stubs to fix this, but I &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; really
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; feel these stubs should be added to libc. &amp;nbsp;I've also copied kib as
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; he
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; has been kind enough to review my work in the past. &amp;nbsp;Thanks.
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; &lt;a href=&quot;http://www.marcuscom.com/downloads/stubs.diff&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.marcuscom.com/downloads/stubs.diff&lt;/a&gt;&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; It is FBSD_1.2 version that we use for symbols added after HEAD
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; become
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; CURRENT-9.
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; Done.
&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; I don't think the symbols belong in FBSD_1.2. &amp;nbsp;They already exist in
&lt;br&gt;&amp;gt;&amp;gt; libthr in a previous namespace. &amp;nbsp;If you use FBSD_1.2, then you
&lt;br&gt;&amp;gt;&amp;gt; probably need to bump them in libthr and libc_r, and add compatible
&lt;br&gt;&amp;gt;&amp;gt; symbols (no problem there since there are no differences) for the
&lt;br&gt;&amp;gt;&amp;gt; previous versions.
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; How would this be done? &amp;nbsp;Would I add an FBSD_1.2 namespace to
&lt;br&gt;&amp;gt; pthread.map, or would FBSD_1.1 be sufficient? &amp;nbsp;How would the
&lt;br&gt;&amp;gt; compatibility symbols be defined?
&lt;/div&gt;&lt;br&gt;I'm away and on an iPhone, you'll have to search for my notes on this &amp;nbsp;
&lt;br&gt;or see how it's been done for other libc compat symbols..
&lt;br&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; Still not sure why libc needs all libpthread stubs. &amp;nbsp;Shouldn't be
&lt;br&gt;&amp;gt;&amp;gt; necessary.
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; Agreed, but the problem comes with the libpthread-stubs port. &amp;nbsp;This &amp;nbsp;
&lt;br&gt;&amp;gt; port
&lt;br&gt;&amp;gt; was added as a dependency of libxcb (which is used by just about
&lt;br&gt;&amp;gt; everything in X). &amp;nbsp;This port defines weak symbols for
&lt;br&gt;&amp;gt; pthread_condattr_destroy and pthread_condattr_init and maps them to a
&lt;br&gt;&amp;gt; function that simply returns 0. &amp;nbsp;The problem is that if a binary is
&lt;br&gt;&amp;gt; linked to both this library and -pthread, and that binary calls
&lt;br&gt;&amp;gt; pthread_condattr_init(), it can be resolved in libpthread-stubs &amp;nbsp;
&lt;br&gt;&amp;gt; instead
&lt;br&gt;&amp;gt; of libthr. &amp;nbsp;When this happens, the init isn't done, and any subsequent
&lt;br&gt;&amp;gt; usage of the pthread_condattr_t structure results in a segfault.
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; I'm certainly open to other suggestions for fixing this.
&lt;/div&gt;&lt;br&gt;You can reference the non-weak underscore versions in libpthread, and &amp;nbsp;
&lt;br&gt;when non-null you know libphread is present and just dereference &amp;nbsp;
&lt;br&gt;them. &amp;nbsp;Or do something similar to libgcc (or is it libstdc++, I &amp;nbsp;
&lt;br&gt;forget) and use pthread_create as you weakly referenced symbol. &amp;nbsp;The &amp;nbsp;
&lt;br&gt;idea is that if the weakly reference symbol is present, then you know &amp;nbsp;
&lt;br&gt;libpthread is present. &amp;nbsp;I may be misusing &amp;quot;reference&amp;quot; instead of &amp;nbsp;
&lt;br&gt;&amp;quot;defined.
&lt;br&gt;&lt;br&gt;static void *create_is_present = pthread_create;
&lt;br&gt;#pragma weak pthread_create
&lt;br&gt;&lt;br&gt;If create_is_present is not NULL then the symbol is present.
&lt;br&gt;&lt;br&gt;On travel, so I can't provide much more info right now.
&lt;br&gt;&lt;br&gt;--
&lt;br&gt;DE
&lt;br&gt;_______________________________________________
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26548815&amp;i=2&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads@...&lt;/a&gt; mailing list
&lt;br&gt;&lt;a href=&quot;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&lt;/a&gt;&lt;br&gt;To unsubscribe, send any mail to &amp;quot;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26548815&amp;i=3&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads-unsubscribe@...&lt;/a&gt;&amp;quot;
&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-PATCH--Add-missing-pthread_condattr_%7Binit%2Cdestroy%7D-stubs-to-libc-tp26538004p26548815.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26548689</id>
	<title>Re: [PATCH] Add missing pthread_condattr_{init,destroy} stubs to libc</title>
	<published>2009-11-27T14:34:19Z</published>
	<updated>2009-11-27T14:34:19Z</updated>
	<author>
		<name>marcus-11</name>
	</author>
	<content type="html">On Sat, 2009-11-28 at 00:30 +0200, Kostik Belousov wrote:
&lt;div class='shrinkable-quote'&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; On Fri, Nov 27, 2009 at 05:28:07PM -0500, Joe Marcus Clarke wrote:
&lt;br&gt;&amp;gt; &amp;gt; On Sat, 2009-11-28 at 00:22 +0200, Kostik Belousov wrote:
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; On Fri, Nov 27, 2009 at 05:11:13PM -0500, Joe Marcus Clarke wrote:
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; I didn't see a better way of fixing this. &amp;nbsp;I'm still fuzzy on how to do
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; the correct symbol map dance for libthr/libc_r. &amp;nbsp;Do you know of any
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; example symbols which had to be updated in this fashion?
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; pthread_condattr_init and _destroy are exported from libthr in FBSD_1.0.
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; namespace. I think stubs should go into FBSD_1.0 namespace in libc then.
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; We nullified one of the use for symver by extending existing
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; namespaces (symbol versioning, as defined by Sun, allowed for dynamic
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; linker to make a guarantee that process does not have unresolved
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; symbols only by checking that all required versions are provided
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; by libraries). My opinion that adding them to FBSD_1.0 is ok.
&lt;br&gt;&amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; That's easy enough. &amp;nbsp;New patch is up.
&lt;br&gt;&amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; &lt;a href=&quot;http://www.marcuscom.com/downloads/stubs.diff&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.marcuscom.com/downloads/stubs.diff&lt;/a&gt;&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; I think symbols should be added in the pthread_* block of the
&lt;br&gt;&amp;gt; libc/gen/Symbol.map, arranged alphabetically.
&lt;/div&gt;&lt;/div&gt;Wasn't sure of that. &amp;nbsp;I had it that way originally, then I thought maybe
&lt;br&gt;they were being organized in order of inclusion (as I saw some others
&lt;br&gt;out of alphabetical order). &amp;nbsp;I can easily shuffle them around.
&lt;br&gt;&lt;br&gt;Joe
&lt;br&gt;&lt;br&gt;-- 
&lt;br&gt;Joe Marcus Clarke
&lt;br&gt;FreeBSD GNOME Team &amp;nbsp; &amp;nbsp; &amp;nbsp;:: &amp;nbsp; &amp;nbsp; &amp;nbsp;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26548689&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;gnome@...&lt;/a&gt;
&lt;br&gt;FreeNode / #freebsd-gnome
&lt;br&gt;&lt;a href=&quot;http://www.FreeBSD.org/gnome&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.FreeBSD.org/gnome&lt;/a&gt;&lt;br&gt;&lt;br /&gt; &lt;div class=&quot;small&quot;&gt;&lt;br/&gt;&lt;img src=&quot;http://old.nabble.com/images/icon_attachment.gif&quot; &gt; &lt;strong&gt;signature.asc&lt;/strong&gt; (203 bytes) &lt;a href=&quot;http://old.nabble.com/attachment/26548689/0/signature.asc&quot; target=&quot;_top&quot;&gt;Download Attachment&lt;/a&gt;&lt;/div&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-PATCH--Add-missing-pthread_condattr_%7Binit%2Cdestroy%7D-stubs-to-libc-tp26538004p26548689.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26548662</id>
	<title>Re: [PATCH] Add missing pthread_condattr_{init, destroy} stubs to libc</title>
	<published>2009-11-27T14:30:42Z</published>
	<updated>2009-11-27T14:30:42Z</updated>
	<author>
		<name>Kostik Belousov</name>
	</author>
	<content type="html">On Fri, Nov 27, 2009 at 05:28:07PM -0500, Joe Marcus Clarke wrote:
&lt;div class='shrinkable-quote'&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; On Sat, 2009-11-28 at 00:22 +0200, Kostik Belousov wrote:
&lt;br&gt;&amp;gt; &amp;gt; On Fri, Nov 27, 2009 at 05:11:13PM -0500, Joe Marcus Clarke wrote:
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; I didn't see a better way of fixing this. &amp;nbsp;I'm still fuzzy on how to do
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; the correct symbol map dance for libthr/libc_r. &amp;nbsp;Do you know of any
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; example symbols which had to be updated in this fashion?
&lt;br&gt;&amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; pthread_condattr_init and _destroy are exported from libthr in FBSD_1.0.
&lt;br&gt;&amp;gt; &amp;gt; namespace. I think stubs should go into FBSD_1.0 namespace in libc then.
&lt;br&gt;&amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; We nullified one of the use for symver by extending existing
&lt;br&gt;&amp;gt; &amp;gt; namespaces (symbol versioning, as defined by Sun, allowed for dynamic
&lt;br&gt;&amp;gt; &amp;gt; linker to make a guarantee that process does not have unresolved
&lt;br&gt;&amp;gt; &amp;gt; symbols only by checking that all required versions are provided
&lt;br&gt;&amp;gt; &amp;gt; by libraries). My opinion that adding them to FBSD_1.0 is ok.
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; That's easy enough. &amp;nbsp;New patch is up.
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; &lt;a href=&quot;http://www.marcuscom.com/downloads/stubs.diff&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.marcuscom.com/downloads/stubs.diff&lt;/a&gt;&lt;/div&gt;&lt;/div&gt;I think symbols should be added in the pthread_* block of the
&lt;br&gt;libc/gen/Symbol.map, arranged alphabetically.
&lt;br&gt;&lt;br /&gt; &lt;div class=&quot;small&quot;&gt;&lt;br/&gt;&lt;img src=&quot;http://old.nabble.com/images/icon_attachment.gif&quot; &gt; &lt;strong&gt;attachment0&lt;/strong&gt; (203 bytes) &lt;a href=&quot;http://old.nabble.com/attachment/26548662/0/attachment0&quot; target=&quot;_top&quot;&gt;Download Attachment&lt;/a&gt;&lt;/div&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-PATCH--Add-missing-pthread_condattr_%7Binit%2Cdestroy%7D-stubs-to-libc-tp26538004p26548662.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26548643</id>
	<title>Re: [PATCH] Add missing pthread_condattr_{init,destroy} stubs to libc</title>
	<published>2009-11-27T14:28:07Z</published>
	<updated>2009-11-27T14:28:07Z</updated>
	<author>
		<name>marcus-11</name>
	</author>
	<content type="html">On Sat, 2009-11-28 at 00:22 +0200, Kostik Belousov wrote:
&lt;div class='shrinkable-quote'&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; On Fri, Nov 27, 2009 at 05:11:13PM -0500, Joe Marcus Clarke wrote:
&lt;br&gt;&amp;gt; &amp;gt; I didn't see a better way of fixing this. &amp;nbsp;I'm still fuzzy on how to do
&lt;br&gt;&amp;gt; &amp;gt; the correct symbol map dance for libthr/libc_r. &amp;nbsp;Do you know of any
&lt;br&gt;&amp;gt; &amp;gt; example symbols which had to be updated in this fashion?
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; pthread_condattr_init and _destroy are exported from libthr in FBSD_1.0.
&lt;br&gt;&amp;gt; namespace. I think stubs should go into FBSD_1.0 namespace in libc then.
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; We nullified one of the use for symver by extending existing
&lt;br&gt;&amp;gt; namespaces (symbol versioning, as defined by Sun, allowed for dynamic
&lt;br&gt;&amp;gt; linker to make a guarantee that process does not have unresolved
&lt;br&gt;&amp;gt; symbols only by checking that all required versions are provided
&lt;br&gt;&amp;gt; by libraries). My opinion that adding them to FBSD_1.0 is ok.
&lt;/div&gt;&lt;/div&gt;That's easy enough. &amp;nbsp;New patch is up.
&lt;br&gt;&lt;br&gt;&lt;a href=&quot;http://www.marcuscom.com/downloads/stubs.diff&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.marcuscom.com/downloads/stubs.diff&lt;/a&gt;&lt;br&gt;&lt;br&gt;Joe
&lt;br&gt;&lt;br&gt;-- 
&lt;br&gt;Joe Marcus Clarke
&lt;br&gt;FreeBSD GNOME Team &amp;nbsp; &amp;nbsp; &amp;nbsp;:: &amp;nbsp; &amp;nbsp; &amp;nbsp;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26548643&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;gnome@...&lt;/a&gt;
&lt;br&gt;FreeNode / #freebsd-gnome
&lt;br&gt;&lt;a href=&quot;http://www.FreeBSD.org/gnome&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.FreeBSD.org/gnome&lt;/a&gt;&lt;br&gt;&lt;br /&gt; &lt;div class=&quot;small&quot;&gt;&lt;br/&gt;&lt;img src=&quot;http://old.nabble.com/images/icon_attachment.gif&quot; &gt; &lt;strong&gt;signature.asc&lt;/strong&gt; (203 bytes) &lt;a href=&quot;http://old.nabble.com/attachment/26548643/0/signature.asc&quot; target=&quot;_top&quot;&gt;Download Attachment&lt;/a&gt;&lt;/div&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-PATCH--Add-missing-pthread_condattr_%7Binit%2Cdestroy%7D-stubs-to-libc-tp26538004p26548643.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26548573</id>
	<title>Re: [PATCH] Add missing pthread_condattr_{init, destroy} stubs to libc</title>
	<published>2009-11-27T14:22:24Z</published>
	<updated>2009-11-27T14:22:24Z</updated>
	<author>
		<name>Kostik Belousov</name>
	</author>
	<content type="html">On Fri, Nov 27, 2009 at 05:11:13PM -0500, Joe Marcus Clarke wrote:
&lt;br&gt;&amp;gt; I didn't see a better way of fixing this. &amp;nbsp;I'm still fuzzy on how to do
&lt;br&gt;&amp;gt; the correct symbol map dance for libthr/libc_r. &amp;nbsp;Do you know of any
&lt;br&gt;&amp;gt; example symbols which had to be updated in this fashion?
&lt;br&gt;&lt;br&gt;pthread_condattr_init and _destroy are exported from libthr in FBSD_1.0.
&lt;br&gt;namespace. I think stubs should go into FBSD_1.0 namespace in libc then.
&lt;br&gt;&lt;br&gt;We nullified one of the use for symver by extending existing
&lt;br&gt;namespaces (symbol versioning, as defined by Sun, allowed for dynamic
&lt;br&gt;linker to make a guarantee that process does not have unresolved
&lt;br&gt;symbols only by checking that all required versions are provided
&lt;br&gt;by libraries). My opinion that adding them to FBSD_1.0 is ok.
&lt;br&gt;&lt;br&gt;Others suggestions are welcome.
&lt;br&gt;&lt;br /&gt; &lt;div class=&quot;small&quot;&gt;&lt;br/&gt;&lt;img src=&quot;http://old.nabble.com/images/icon_attachment.gif&quot; &gt; &lt;strong&gt;attachment0&lt;/strong&gt; (203 bytes) &lt;a href=&quot;http://old.nabble.com/attachment/26548573/0/attachment0&quot; target=&quot;_top&quot;&gt;Download Attachment&lt;/a&gt;&lt;/div&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-PATCH--Add-missing-pthread_condattr_%7Binit%2Cdestroy%7D-stubs-to-libc-tp26538004p26548573.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26548504</id>
	<title>Re: [PATCH] Add missing pthread_condattr_{init,destroy} stubs to libc</title>
	<published>2009-11-27T14:11:13Z</published>
	<updated>2009-11-27T14:11:13Z</updated>
	<author>
		<name>marcus-11</name>
	</author>
	<content type="html">On Sat, 2009-11-28 at 00:07 +0200, Kostik Belousov wrote:
&lt;div class='shrinkable-quote'&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; On Fri, Nov 27, 2009 at 04:53:20PM -0500, Joe Marcus Clarke wrote:
&lt;br&gt;&amp;gt; &amp;gt; On Fri, 2009-11-27 at 23:30 +0200, Kostik Belousov wrote:
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; On Fri, Nov 27, 2009 at 04:19:38PM -0500, Daniel Eischen wrote:
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; On Nov 27, 2009, at 2:14 PM, Joe Marcus Clarke &amp;lt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26548504&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;marcus@...&lt;/a&gt;&amp;gt; &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; wrote:
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; &amp;gt;On Fri, 2009-11-27 at 15:12 +0200, Kostik Belousov wrote:
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;On Fri, Nov 27, 2009 at 12:15:18AM -0500, Joe Marcus Clarke wrote:
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;I would like permission to commit this patch which adds missing
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;pthread_condattr_{init,destroy} symbols to libc. &amp;nbsp;I think I did the
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;symbol addition correctly (and it seems to work). &amp;nbsp;Without this, the
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;weak symbols added in the libpthread-stubs port conflict with &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;those in
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;libthr, and applications with use these symbols can crash.
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;I have temporarily hacked libpthread-stubs to fix this, but I really
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;feel these stubs should be added to libc. &amp;nbsp;I've also copied kib as &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;he
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;has been kind enough to review my work in the past. &amp;nbsp;Thanks.
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;&lt;a href=&quot;http://www.marcuscom.com/downloads/stubs.diff&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.marcuscom.com/downloads/stubs.diff&lt;/a&gt;&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;It is FBSD_1.2 version that we use for symbols added after HEAD &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;become
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;CURRENT-9.
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; &amp;gt;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; &amp;gt;Done.
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; I don't think the symbols belong in FBSD_1.2. &amp;nbsp;They already exist in &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; libthr in a previous namespace. &amp;nbsp;If you use FBSD_1.2, then you &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; probably need to bump them in libthr and libc_r, and add compatible &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; symbols (no problem there since there are no differences) for the &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; previous versions.
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; Oh, yes.
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; Still not sure why libc needs all libpthread stubs. &amp;nbsp;Shouldn't be &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt; necessary.
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; The privately discussed plan for 9.0 is to have libthr merged into
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; libc, and have libpthread and libthr as only filter object against libc
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; providing pthread_* and related symbols.
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; This would eliminate the need for pthread stubs and solve the issues
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; with (wrongly built) binaries that do not link to libthr but dlopen()
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; libraries that are linked with it.
&lt;br&gt;&amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; Yeah, I think that would be a great overall solution. &amp;nbsp;However, in this
&lt;br&gt;&amp;gt; &amp;gt; case, the binaries in question ARE linked with -pthread. &amp;nbsp;The problem
&lt;br&gt;&amp;gt; &amp;gt; can be easily seen by taking this C program:
&lt;br&gt;&amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; #include &amp;lt;sys/time.h&amp;gt;
&lt;br&gt;&amp;gt; &amp;gt; #include &amp;lt;pthread.h&amp;gt;
&lt;br&gt;&amp;gt; &amp;gt; #include &amp;lt;string.h&amp;gt;
&lt;br&gt;&amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; int
&lt;br&gt;&amp;gt; &amp;gt; main(void) {
&lt;br&gt;&amp;gt; &amp;gt; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; pthread_condattr_t attr;
&lt;br&gt;&amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; pthread_condattr_init (&amp;attr);
&lt;br&gt;&amp;gt; &amp;gt; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; pthread_condattr_setclock (&amp;attr, CLOCK_MONOTONIC);
&lt;br&gt;&amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; pthread_condattr_destroy (&amp;attr);
&lt;br&gt;&amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; return 0;
&lt;br&gt;&amp;gt; &amp;gt; }
&lt;br&gt;&amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; And compiling it as:
&lt;br&gt;&amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; cc -o xxx -L/usr/local/lib -lpthread-stubs -pthread xxx.c
&lt;br&gt;&amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; You will need devel/libpthread-stubs (version 0.3) installed. &amp;nbsp;When you
&lt;br&gt;&amp;gt; &amp;gt; run it, it will segfault. &amp;nbsp;If you then rebuild libc and libthr with my
&lt;br&gt;&amp;gt; &amp;gt; stubs.diff patch, then rebuild libpthread-stubs, the problem will go
&lt;br&gt;&amp;gt; &amp;gt; away.
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; I see. What happen there is that both libpthread-stubs and libthr
&lt;br&gt;&amp;gt; provide _weak_ symbols pthread_condattr_destroy and pthread_condattr_init.
&lt;br&gt;&amp;gt; Actually, these two symbols are the only exported symbols from stubs
&lt;br&gt;&amp;gt; library. Due to specified library order, rtld for xxx resolves these
&lt;br&gt;&amp;gt; symbols from stubs, not from libthr. But pthread_condattr_setclock
&lt;br&gt;&amp;gt; is only exported weak from libthr, and it gets used.
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; This ends up supplying initialized attributes to pthread_condattr_setclock.
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; Your patch makes libc provide these two weak symbols, and then
&lt;br&gt;&amp;gt; stubs seems to become empty library.
&lt;/div&gt;&lt;/div&gt;100% correct all around. &amp;nbsp;In fact, if you read the manifesto for
&lt;br&gt;libpthread-stubs, it is designed to be an empty library on systems which
&lt;br&gt;provide all of the necessary stubs. &amp;nbsp;In that case, it just provides its
&lt;br&gt;pkg-config file.
&lt;br&gt;&lt;br&gt;I didn't see a better way of fixing this. &amp;nbsp;I'm still fuzzy on how to do
&lt;br&gt;the correct symbol map dance for libthr/libc_r. &amp;nbsp;Do you know of any
&lt;br&gt;example symbols which had to be updated in this fashion?
&lt;br&gt;&lt;br&gt;Joe
&lt;br&gt;&lt;br&gt;-- 
&lt;br&gt;Joe Marcus Clarke
&lt;br&gt;FreeBSD GNOME Team &amp;nbsp; &amp;nbsp; &amp;nbsp;:: &amp;nbsp; &amp;nbsp; &amp;nbsp;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26548504&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;gnome@...&lt;/a&gt;
&lt;br&gt;FreeNode / #freebsd-gnome
&lt;br&gt;&lt;a href=&quot;http://www.FreeBSD.org/gnome&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.FreeBSD.org/gnome&lt;/a&gt;&lt;br&gt;&lt;br /&gt; &lt;div class=&quot;small&quot;&gt;&lt;br/&gt;&lt;img src=&quot;http://old.nabble.com/images/icon_attachment.gif&quot; &gt; &lt;strong&gt;signature.asc&lt;/strong&gt; (203 bytes) &lt;a href=&quot;http://old.nabble.com/attachment/26548504/0/signature.asc&quot; target=&quot;_top&quot;&gt;Download Attachment&lt;/a&gt;&lt;/div&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-PATCH--Add-missing-pthread_condattr_%7Binit%2Cdestroy%7D-stubs-to-libc-tp26538004p26548504.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26548453</id>
	<title>Re: [PATCH] Add missing pthread_condattr_{init, destroy} stubs to libc</title>
	<published>2009-11-27T14:07:06Z</published>
	<updated>2009-11-27T14:07:06Z</updated>
	<author>
		<name>Kostik Belousov</name>
	</author>
	<content type="html">On Fri, Nov 27, 2009 at 04:53:20PM -0500, Joe Marcus Clarke wrote:
&lt;div class='shrinkable-quote'&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; On Fri, 2009-11-27 at 23:30 +0200, Kostik Belousov wrote:
&lt;br&gt;&amp;gt; &amp;gt; On Fri, Nov 27, 2009 at 04:19:38PM -0500, Daniel Eischen wrote:
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; On Nov 27, 2009, at 2:14 PM, Joe Marcus Clarke &amp;lt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26548453&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;marcus@...&lt;/a&gt;&amp;gt; &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; wrote:
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt;On Fri, 2009-11-27 at 15:12 +0200, Kostik Belousov wrote:
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;On Fri, Nov 27, 2009 at 12:15:18AM -0500, Joe Marcus Clarke wrote:
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;I would like permission to commit this patch which adds missing
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;pthread_condattr_{init,destroy} symbols to libc. &amp;nbsp;I think I did the
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;symbol addition correctly (and it seems to work). &amp;nbsp;Without this, the
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;weak symbols added in the libpthread-stubs port conflict with &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;those in
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;libthr, and applications with use these symbols can crash.
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;I have temporarily hacked libpthread-stubs to fix this, but I really
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;feel these stubs should be added to libc. &amp;nbsp;I've also copied kib as &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;he
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;has been kind enough to review my work in the past. &amp;nbsp;Thanks.
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;&lt;a href=&quot;http://www.marcuscom.com/downloads/stubs.diff&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.marcuscom.com/downloads/stubs.diff&lt;/a&gt;&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;It is FBSD_1.2 version that we use for symbols added after HEAD &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;become
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt;&amp;gt;CURRENT-9.
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; &amp;gt;Done.
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; I don't think the symbols belong in FBSD_1.2. &amp;nbsp;They already exist in &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; libthr in a previous namespace. &amp;nbsp;If you use FBSD_1.2, then you &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; probably need to bump them in libthr and libc_r, and add compatible &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; symbols (no problem there since there are no differences) for the &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; previous versions.
&lt;br&gt;&amp;gt; &amp;gt; Oh, yes.
&lt;br&gt;&amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; Still not sure why libc needs all libpthread stubs. &amp;nbsp;Shouldn't be &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; necessary.
&lt;br&gt;&amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; The privately discussed plan for 9.0 is to have libthr merged into
&lt;br&gt;&amp;gt; &amp;gt; libc, and have libpthread and libthr as only filter object against libc
&lt;br&gt;&amp;gt; &amp;gt; providing pthread_* and related symbols.
&lt;br&gt;&amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; This would eliminate the need for pthread stubs and solve the issues
&lt;br&gt;&amp;gt; &amp;gt; with (wrongly built) binaries that do not link to libthr but dlopen()
&lt;br&gt;&amp;gt; &amp;gt; libraries that are linked with it.
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; Yeah, I think that would be a great overall solution. &amp;nbsp;However, in this
&lt;br&gt;&amp;gt; case, the binaries in question ARE linked with -pthread. &amp;nbsp;The problem
&lt;br&gt;&amp;gt; can be easily seen by taking this C program:
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; #include &amp;lt;sys/time.h&amp;gt;
&lt;br&gt;&amp;gt; #include &amp;lt;pthread.h&amp;gt;
&lt;br&gt;&amp;gt; #include &amp;lt;string.h&amp;gt;
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; int
&lt;br&gt;&amp;gt; main(void) {
&lt;br&gt;&amp;gt; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; pthread_condattr_t attr;
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; pthread_condattr_init (&amp;attr);
&lt;br&gt;&amp;gt; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; pthread_condattr_setclock (&amp;attr, CLOCK_MONOTONIC);
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; pthread_condattr_destroy (&amp;attr);
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; return 0;
&lt;br&gt;&amp;gt; }
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; And compiling it as:
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; cc -o xxx -L/usr/local/lib -lpthread-stubs -pthread xxx.c
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; You will need devel/libpthread-stubs (version 0.3) installed. &amp;nbsp;When you
&lt;br&gt;&amp;gt; run it, it will segfault. &amp;nbsp;If you then rebuild libc and libthr with my
&lt;br&gt;&amp;gt; stubs.diff patch, then rebuild libpthread-stubs, the problem will go
&lt;br&gt;&amp;gt; away.
&lt;/div&gt;&lt;/div&gt;I see. What happen there is that both libpthread-stubs and libthr
&lt;br&gt;provide _weak_ symbols pthread_condattr_destroy and pthread_condattr_init.
&lt;br&gt;Actually, these two symbols are the only exported symbols from stubs
&lt;br&gt;library. Due to specified library order, rtld for xxx resolves these
&lt;br&gt;symbols from stubs, not from libthr. But pthread_condattr_setclock
&lt;br&gt;is only exported weak from libthr, and it gets used.
&lt;br&gt;&lt;br&gt;This ends up supplying initialized attributes to pthread_condattr_setclock.
&lt;br&gt;&lt;br&gt;Your patch makes libc provide these two weak symbols, and then
&lt;br&gt;stubs seems to become empty library.
&lt;br&gt;&lt;br /&gt; &lt;div class=&quot;small&quot;&gt;&lt;br/&gt;&lt;img src=&quot;http://old.nabble.com/images/icon_attachment.gif&quot; &gt; &lt;strong&gt;attachment0&lt;/strong&gt; (203 bytes) &lt;a href=&quot;http://old.nabble.com/attachment/26548453/0/attachment0&quot; target=&quot;_top&quot;&gt;Download Attachment&lt;/a&gt;&lt;/div&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-PATCH--Add-missing-pthread_condattr_%7Binit%2Cdestroy%7D-stubs-to-libc-tp26538004p26548453.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26548178</id>
	<title>Re: [PATCH] Add missing pthread_condattr_{init,destroy} stubs to libc</title>
	<published>2009-11-27T13:53:20Z</published>
	<updated>2009-11-27T13:53:20Z</updated>
	<author>
		<name>marcus-11</name>
	</author>
	<content type="html">On Fri, 2009-11-27 at 23:30 +0200, Kostik Belousov wrote:
&lt;div class='shrinkable-quote'&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; On Fri, Nov 27, 2009 at 04:19:38PM -0500, Daniel Eischen wrote:
&lt;br&gt;&amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; On Nov 27, 2009, at 2:14 PM, Joe Marcus Clarke &amp;lt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26548178&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;marcus@...&lt;/a&gt;&amp;gt; &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; wrote:
&lt;br&gt;&amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt;On Fri, 2009-11-27 at 15:12 +0200, Kostik Belousov wrote:
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt;&amp;gt;On Fri, Nov 27, 2009 at 12:15:18AM -0500, Joe Marcus Clarke wrote:
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;I would like permission to commit this patch which adds missing
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;pthread_condattr_{init,destroy} symbols to libc. &amp;nbsp;I think I did the
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;symbol addition correctly (and it seems to work). &amp;nbsp;Without this, the
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;weak symbols added in the libpthread-stubs port conflict with &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;those in
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;libthr, and applications with use these symbols can crash.
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;I have temporarily hacked libpthread-stubs to fix this, but I really
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;feel these stubs should be added to libc. &amp;nbsp;I've also copied kib as &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;he
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;has been kind enough to review my work in the past. &amp;nbsp;Thanks.
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt;&amp;gt;&amp;gt;&lt;a href=&quot;http://www.marcuscom.com/downloads/stubs.diff&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.marcuscom.com/downloads/stubs.diff&lt;/a&gt;&lt;br&gt;&amp;gt; &amp;gt; &amp;gt;&amp;gt;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt;&amp;gt;It is FBSD_1.2 version that we use for symbols added after HEAD &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt;&amp;gt;become
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt;&amp;gt;CURRENT-9.
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt;
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt;Done.
&lt;br&gt;&amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; I don't think the symbols belong in FBSD_1.2. &amp;nbsp;They already exist in &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; libthr in a previous namespace. &amp;nbsp;If you use FBSD_1.2, then you &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; probably need to bump them in libthr and libc_r, and add compatible &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; symbols (no problem there since there are no differences) for the &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; previous versions.
&lt;br&gt;&amp;gt; Oh, yes.
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; Still not sure why libc needs all libpthread stubs. &amp;nbsp;Shouldn't be &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt; necessary.
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; The privately discussed plan for 9.0 is to have libthr merged into
&lt;br&gt;&amp;gt; libc, and have libpthread and libthr as only filter object against libc
&lt;br&gt;&amp;gt; providing pthread_* and related symbols.
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; This would eliminate the need for pthread stubs and solve the issues
&lt;br&gt;&amp;gt; with (wrongly built) binaries that do not link to libthr but dlopen()
&lt;br&gt;&amp;gt; libraries that are linked with it.
&lt;/div&gt;&lt;/div&gt;Yeah, I think that would be a great overall solution. &amp;nbsp;However, in this
&lt;br&gt;case, the binaries in question ARE linked with -pthread. &amp;nbsp;The problem
&lt;br&gt;can be easily seen by taking this C program:
&lt;br&gt;&lt;br&gt;#include &amp;lt;sys/time.h&amp;gt;
&lt;br&gt;#include &amp;lt;pthread.h&amp;gt;
&lt;br&gt;#include &amp;lt;string.h&amp;gt;
&lt;br&gt;&lt;br&gt;int
&lt;br&gt;main(void) {
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; pthread_condattr_t attr;
&lt;br&gt;&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; pthread_condattr_init (&amp;attr);
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; pthread_condattr_setclock (&amp;attr, CLOCK_MONOTONIC);
&lt;br&gt;&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; pthread_condattr_destroy (&amp;attr);
&lt;br&gt;&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; return 0;
&lt;br&gt;}
&lt;br&gt;&lt;br&gt;And compiling it as:
&lt;br&gt;&lt;br&gt;cc -o xxx -L/usr/local/lib -lpthread-stubs -pthread xxx.c
&lt;br&gt;&lt;br&gt;You will need devel/libpthread-stubs (version 0.3) installed. &amp;nbsp;When you
&lt;br&gt;run it, it will segfault. &amp;nbsp;If you then rebuild libc and libthr with my
&lt;br&gt;stubs.diff patch, then rebuild libpthread-stubs, the problem will go
&lt;br&gt;away.
&lt;br&gt;&lt;br&gt;Joe
&lt;br&gt;&lt;br&gt;-- 
&lt;br&gt;Joe Marcus Clarke
&lt;br&gt;FreeBSD GNOME Team &amp;nbsp; &amp;nbsp; &amp;nbsp;:: &amp;nbsp; &amp;nbsp; &amp;nbsp;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26548178&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;gnome@...&lt;/a&gt;
&lt;br&gt;FreeNode / #freebsd-gnome
&lt;br&gt;&lt;a href=&quot;http://www.FreeBSD.org/gnome&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.FreeBSD.org/gnome&lt;/a&gt;&lt;br&gt;&lt;br /&gt; &lt;div class=&quot;small&quot;&gt;&lt;br/&gt;&lt;img src=&quot;http://old.nabble.com/images/icon_attachment.gif&quot; &gt; &lt;strong&gt;signature.asc&lt;/strong&gt; (203 bytes) &lt;a href=&quot;http://old.nabble.com/attachment/26548178/0/signature.asc&quot; target=&quot;_top&quot;&gt;Download Attachment&lt;/a&gt;&lt;/div&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-PATCH--Add-missing-pthread_condattr_%7Binit%2Cdestroy%7D-stubs-to-libc-tp26538004p26548178.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26548147</id>
	<title>Re: [PATCH] Add missing pthread_condattr_{init,destroy} stubs to libc</title>
	<published>2009-11-27T13:47:14Z</published>
	<updated>2009-11-27T13:47:14Z</updated>
	<author>
		<name>marcus-11</name>
	</author>
	<content type="html">On Fri, 2009-11-27 at 16:19 -0500, Daniel Eischen wrote:
&lt;div class='shrinkable-quote'&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; On Nov 27, 2009, at 2:14 PM, Joe Marcus Clarke &amp;lt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26548147&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;marcus@...&lt;/a&gt;&amp;gt; &amp;nbsp;
&lt;br&gt;&amp;gt; wrote:
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; On Fri, 2009-11-27 at 15:12 +0200, Kostik Belousov wrote:
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt; On Fri, Nov 27, 2009 at 12:15:18AM -0500, Joe Marcus Clarke wrote:
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; I would like permission to commit this patch which adds missing
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; pthread_condattr_{init,destroy} symbols to libc. &amp;nbsp;I think I did the
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; symbol addition correctly (and it seems to work). &amp;nbsp;Without this, the
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; weak symbols added in the libpthread-stubs port conflict with &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; those in
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; libthr, and applications with use these symbols can crash.
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; I have temporarily hacked libpthread-stubs to fix this, but I really
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; feel these stubs should be added to libc. &amp;nbsp;I've also copied kib as &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; he
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; has been kind enough to review my work in the past. &amp;nbsp;Thanks.
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; &lt;a href=&quot;http://www.marcuscom.com/downloads/stubs.diff&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.marcuscom.com/downloads/stubs.diff&lt;/a&gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt; It is FBSD_1.2 version that we use for symbols added after HEAD &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt; become
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt; CURRENT-9.
&lt;br&gt;&amp;gt; &amp;gt;
&lt;br&gt;&amp;gt; &amp;gt; Done.
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; I don't think the symbols belong in FBSD_1.2. &amp;nbsp;They already exist in &amp;nbsp;
&lt;br&gt;&amp;gt; libthr in a previous namespace. &amp;nbsp;If you use FBSD_1.2, then you &amp;nbsp;
&lt;br&gt;&amp;gt; probably need to bump them in libthr and libc_r, and add compatible &amp;nbsp;
&lt;br&gt;&amp;gt; symbols (no problem there since there are no differences) for the &amp;nbsp;
&lt;br&gt;&amp;gt; previous versions.
&lt;/div&gt;&lt;/div&gt;How would this be done? &amp;nbsp;Would I add an FBSD_1.2 namespace to
&lt;br&gt;pthread.map, or would FBSD_1.1 be sufficient? &amp;nbsp;How would the
&lt;br&gt;compatibility symbols be defined?
&lt;br&gt;&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; Still not sure why libc needs all libpthread stubs. &amp;nbsp;Shouldn't be &amp;nbsp;
&lt;br&gt;&amp;gt; necessary.
&lt;br&gt;&lt;br&gt;Agreed, but the problem comes with the libpthread-stubs port. &amp;nbsp;This port
&lt;br&gt;was added as a dependency of libxcb (which is used by just about
&lt;br&gt;everything in X). &amp;nbsp;This port defines weak symbols for
&lt;br&gt;pthread_condattr_destroy and pthread_condattr_init and maps them to a
&lt;br&gt;function that simply returns 0. &amp;nbsp;The problem is that if a binary is
&lt;br&gt;linked to both this library and -pthread, and that binary calls
&lt;br&gt;pthread_condattr_init(), it can be resolved in libpthread-stubs instead
&lt;br&gt;of libthr. &amp;nbsp;When this happens, the init isn't done, and any subsequent
&lt;br&gt;usage of the pthread_condattr_t structure results in a segfault.
&lt;br&gt;&lt;br&gt;I'm certainly open to other suggestions for fixing this.
&lt;br&gt;&lt;br&gt;Joe
&lt;br&gt;&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; --
&lt;br&gt;&amp;gt; DE
&lt;br&gt;&amp;gt; 
&lt;br&gt;-- 
&lt;br&gt;Joe Marcus Clarke
&lt;br&gt;FreeBSD GNOME Team &amp;nbsp; &amp;nbsp; &amp;nbsp;:: &amp;nbsp; &amp;nbsp; &amp;nbsp;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26548147&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;gnome@...&lt;/a&gt;
&lt;br&gt;FreeNode / #freebsd-gnome
&lt;br&gt;&lt;a href=&quot;http://www.FreeBSD.org/gnome&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.FreeBSD.org/gnome&lt;/a&gt;&lt;br&gt;&lt;br /&gt; &lt;div class=&quot;small&quot;&gt;&lt;br/&gt;&lt;img src=&quot;http://old.nabble.com/images/icon_attachment.gif&quot; &gt; &lt;strong&gt;signature.asc&lt;/strong&gt; (203 bytes) &lt;a href=&quot;http://old.nabble.com/attachment/26548147/0/signature.asc&quot; target=&quot;_top&quot;&gt;Download Attachment&lt;/a&gt;&lt;/div&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-PATCH--Add-missing-pthread_condattr_%7Binit%2Cdestroy%7D-stubs-to-libc-tp26538004p26548147.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26547973</id>
	<title>Re: [PATCH] Add missing pthread_condattr_{init, destroy} stubs to libc</title>
	<published>2009-11-27T13:30:46Z</published>
	<updated>2009-11-27T13:30:46Z</updated>
	<author>
		<name>Kostik Belousov</name>
	</author>
	<content type="html">On Fri, Nov 27, 2009 at 04:19:38PM -0500, Daniel Eischen wrote:
&lt;div class='shrinkable-quote'&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; On Nov 27, 2009, at 2:14 PM, Joe Marcus Clarke &amp;lt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26547973&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;marcus@...&lt;/a&gt;&amp;gt; &amp;nbsp;
&lt;br&gt;&amp;gt; wrote:
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt;On Fri, 2009-11-27 at 15:12 +0200, Kostik Belousov wrote:
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;On Fri, Nov 27, 2009 at 12:15:18AM -0500, Joe Marcus Clarke wrote:
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;I would like permission to commit this patch which adds missing
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;pthread_condattr_{init,destroy} symbols to libc. &amp;nbsp;I think I did the
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;symbol addition correctly (and it seems to work). &amp;nbsp;Without this, the
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;weak symbols added in the libpthread-stubs port conflict with &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;those in
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;libthr, and applications with use these symbols can crash.
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;I have temporarily hacked libpthread-stubs to fix this, but I really
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;feel these stubs should be added to libc. &amp;nbsp;I've also copied kib as &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;he
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;has been kind enough to review my work in the past. &amp;nbsp;Thanks.
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&lt;a href=&quot;http://www.marcuscom.com/downloads/stubs.diff&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.marcuscom.com/downloads/stubs.diff&lt;/a&gt;&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;It is FBSD_1.2 version that we use for symbols added after HEAD &amp;nbsp;
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;become
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;CURRENT-9.
&lt;br&gt;&amp;gt; &amp;gt;
&lt;br&gt;&amp;gt; &amp;gt;Done.
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; I don't think the symbols belong in FBSD_1.2. &amp;nbsp;They already exist in &amp;nbsp;
&lt;br&gt;&amp;gt; libthr in a previous namespace. &amp;nbsp;If you use FBSD_1.2, then you &amp;nbsp;
&lt;br&gt;&amp;gt; probably need to bump them in libthr and libc_r, and add compatible &amp;nbsp;
&lt;br&gt;&amp;gt; symbols (no problem there since there are no differences) for the &amp;nbsp;
&lt;br&gt;&amp;gt; previous versions.
&lt;/div&gt;Oh, yes.
&lt;/div&gt;&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; Still not sure why libc needs all libpthread stubs. &amp;nbsp;Shouldn't be &amp;nbsp;
&lt;br&gt;&amp;gt; necessary.
&lt;br&gt;&lt;br&gt;The privately discussed plan for 9.0 is to have libthr merged into
&lt;br&gt;libc, and have libpthread and libthr as only filter object against libc
&lt;br&gt;providing pthread_* and related symbols.
&lt;br&gt;&lt;br&gt;This would eliminate the need for pthread stubs and solve the issues
&lt;br&gt;with (wrongly built) binaries that do not link to libthr but dlopen()
&lt;br&gt;libraries that are linked with it.
&lt;br&gt;&lt;br /&gt; &lt;div class=&quot;small&quot;&gt;&lt;br/&gt;&lt;img src=&quot;http://old.nabble.com/images/icon_attachment.gif&quot; &gt; &lt;strong&gt;attachment0&lt;/strong&gt; (203 bytes) &lt;a href=&quot;http://old.nabble.com/attachment/26547973/0/attachment0&quot; target=&quot;_top&quot;&gt;Download Attachment&lt;/a&gt;&lt;/div&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-PATCH--Add-missing-pthread_condattr_%7Binit%2Cdestroy%7D-stubs-to-libc-tp26538004p26547973.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26547986</id>
	<title>Re: [PATCH] Add missing pthread_condattr_{init, destroy} stubs to libc</title>
	<published>2009-11-27T13:19:38Z</published>
	<updated>2009-11-27T13:19:38Z</updated>
	<author>
		<name>Daniel Eischen-2</name>
	</author>
	<content type="html">&lt;br&gt;On Nov 27, 2009, at 2:14 PM, Joe Marcus Clarke &amp;lt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26547986&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;marcus@...&lt;/a&gt;&amp;gt; &amp;nbsp;
&lt;br&gt;wrote:
&lt;br&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; On Fri, 2009-11-27 at 15:12 +0200, Kostik Belousov wrote:
&lt;br&gt;&amp;gt;&amp;gt; On Fri, Nov 27, 2009 at 12:15:18AM -0500, Joe Marcus Clarke wrote:
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; I would like permission to commit this patch which adds missing
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; pthread_condattr_{init,destroy} symbols to libc. &amp;nbsp;I think I did the
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; symbol addition correctly (and it seems to work). &amp;nbsp;Without this, the
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; weak symbols added in the libpthread-stubs port conflict with &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; those in
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; libthr, and applications with use these symbols can crash.
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; I have temporarily hacked libpthread-stubs to fix this, but I really
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; feel these stubs should be added to libc. &amp;nbsp;I've also copied kib as &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; he
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; has been kind enough to review my work in the past. &amp;nbsp;Thanks.
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; &lt;a href=&quot;http://www.marcuscom.com/downloads/stubs.diff&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.marcuscom.com/downloads/stubs.diff&lt;/a&gt;&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; It is FBSD_1.2 version that we use for symbols added after HEAD &amp;nbsp;
&lt;br&gt;&amp;gt;&amp;gt; become
&lt;br&gt;&amp;gt;&amp;gt; CURRENT-9.
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; Done.
&lt;/div&gt;&lt;br&gt;I don't think the symbols belong in FBSD_1.2. &amp;nbsp;They already exist in &amp;nbsp;
&lt;br&gt;libthr in a previous namespace. &amp;nbsp;If you use FBSD_1.2, then you &amp;nbsp;
&lt;br&gt;probably need to bump them in libthr and libc_r, and add compatible &amp;nbsp;
&lt;br&gt;symbols (no problem there since there are no differences) for the &amp;nbsp;
&lt;br&gt;previous versions.
&lt;br&gt;&lt;br&gt;Still not sure why libc needs all libpthread stubs. &amp;nbsp;Shouldn't be &amp;nbsp;
&lt;br&gt;necessary.
&lt;br&gt;&lt;br&gt;--
&lt;br&gt;DE
&lt;br&gt;_______________________________________________
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26547986&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads@...&lt;/a&gt; mailing list
&lt;br&gt;&lt;a href=&quot;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&lt;/a&gt;&lt;br&gt;To unsubscribe, send any mail to &amp;quot;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26547986&amp;i=2&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads-unsubscribe@...&lt;/a&gt;&amp;quot;
&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-PATCH--Add-missing-pthread_condattr_%7Binit%2Cdestroy%7D-stubs-to-libc-tp26538004p26547986.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26546715</id>
	<title>Re: [PATCH] Add missing pthread_condattr_{init,destroy} stubs to libc</title>
	<published>2009-11-27T11:14:08Z</published>
	<updated>2009-11-27T11:14:08Z</updated>
	<author>
		<name>marcus-11</name>
	</author>
	<content type="html">On Fri, 2009-11-27 at 15:12 +0200, Kostik Belousov wrote:
&lt;div class='shrinkable-quote'&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; On Fri, Nov 27, 2009 at 12:15:18AM -0500, Joe Marcus Clarke wrote:
&lt;br&gt;&amp;gt; &amp;gt; I would like permission to commit this patch which adds missing
&lt;br&gt;&amp;gt; &amp;gt; pthread_condattr_{init,destroy} symbols to libc. &amp;nbsp;I think I did the
&lt;br&gt;&amp;gt; &amp;gt; symbol addition correctly (and it seems to work). &amp;nbsp;Without this, the
&lt;br&gt;&amp;gt; &amp;gt; weak symbols added in the libpthread-stubs port conflict with those in
&lt;br&gt;&amp;gt; &amp;gt; libthr, and applications with use these symbols can crash.
&lt;br&gt;&amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; I have temporarily hacked libpthread-stubs to fix this, but I really
&lt;br&gt;&amp;gt; &amp;gt; feel these stubs should be added to libc. &amp;nbsp;I've also copied kib as he
&lt;br&gt;&amp;gt; &amp;gt; has been kind enough to review my work in the past. &amp;nbsp;Thanks.
&lt;br&gt;&amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; &lt;a href=&quot;http://www.marcuscom.com/downloads/stubs.diff&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.marcuscom.com/downloads/stubs.diff&lt;/a&gt;&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; It is FBSD_1.2 version that we use for symbols added after HEAD become
&lt;br&gt;&amp;gt; CURRENT-9.
&lt;/div&gt;&lt;/div&gt;Done.
&lt;br&gt;&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; I think that you shall change lib/libc/libc_private.h, adding
&lt;br&gt;&amp;gt; corresponding definitions for the PJT_CONDATTR_DESTROY/PJT_CONDATTR_INIT
&lt;br&gt;&amp;gt; indexes.
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; Is the patch buildable ?
&lt;br&gt;&lt;br&gt;Yes, but only because my machine had the libc_private.h chunk which I
&lt;br&gt;forgot in the diff.
&lt;br&gt;&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; Interesting question is whether these changes are mergeable to the
&lt;br&gt;&amp;gt; stable branch. Possibly yes, if we declare that rtld/libc/libthr shall
&lt;br&gt;&amp;gt; be built from the consistent source snapshot.
&lt;br&gt;&lt;br&gt;I would like to merge these changes to RELENG_8, RELENG_7, and RELENG_6
&lt;br&gt;if possible. &amp;nbsp;Anything which depends on dbus (e.g. GNOME) will just
&lt;br&gt;crash without them. &amp;nbsp;In the meantime, I have hacked libpthread-stubs,
&lt;br&gt;but I really think this is the more correct fix.
&lt;br&gt;&lt;br&gt;&lt;a href=&quot;http://www.marcuscom.com/downloads/stubs.diff&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.marcuscom.com/downloads/stubs.diff&lt;/a&gt;&lt;br&gt;&lt;br&gt;Thanks for the review.
&lt;br&gt;&lt;br&gt;Joe
&lt;br&gt;&lt;br&gt;-- 
&lt;br&gt;Joe Marcus Clarke
&lt;br&gt;FreeBSD GNOME Team &amp;nbsp; &amp;nbsp; &amp;nbsp;:: &amp;nbsp; &amp;nbsp; &amp;nbsp;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26546715&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;gnome@...&lt;/a&gt;
&lt;br&gt;FreeNode / #freebsd-gnome
&lt;br&gt;&lt;a href=&quot;http://www.FreeBSD.org/gnome&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.FreeBSD.org/gnome&lt;/a&gt;&lt;br&gt;&lt;br /&gt; &lt;div class=&quot;small&quot;&gt;&lt;br/&gt;&lt;img src=&quot;http://old.nabble.com/images/icon_attachment.gif&quot; &gt; &lt;strong&gt;signature.asc&lt;/strong&gt; (203 bytes) &lt;a href=&quot;http://old.nabble.com/attachment/26546715/0/signature.asc&quot; target=&quot;_top&quot;&gt;Download Attachment&lt;/a&gt;&lt;/div&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-PATCH--Add-missing-pthread_condattr_%7Binit%2Cdestroy%7D-stubs-to-libc-tp26538004p26546715.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26542359</id>
	<title>Re: [PATCH] Add missing pthread_condattr_{init, destroy} stubs to libc</title>
	<published>2009-11-27T05:12:42Z</published>
	<updated>2009-11-27T05:12:42Z</updated>
	<author>
		<name>Kostik Belousov</name>
	</author>
	<content type="html">On Fri, Nov 27, 2009 at 12:15:18AM -0500, Joe Marcus Clarke wrote:
&lt;div class='shrinkable-quote'&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; I would like permission to commit this patch which adds missing
&lt;br&gt;&amp;gt; pthread_condattr_{init,destroy} symbols to libc. &amp;nbsp;I think I did the
&lt;br&gt;&amp;gt; symbol addition correctly (and it seems to work). &amp;nbsp;Without this, the
&lt;br&gt;&amp;gt; weak symbols added in the libpthread-stubs port conflict with those in
&lt;br&gt;&amp;gt; libthr, and applications with use these symbols can crash.
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; I have temporarily hacked libpthread-stubs to fix this, but I really
&lt;br&gt;&amp;gt; feel these stubs should be added to libc. &amp;nbsp;I've also copied kib as he
&lt;br&gt;&amp;gt; has been kind enough to review my work in the past. &amp;nbsp;Thanks.
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; &lt;a href=&quot;http://www.marcuscom.com/downloads/stubs.diff&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.marcuscom.com/downloads/stubs.diff&lt;/a&gt;&lt;/div&gt;&lt;/div&gt;It is FBSD_1.2 version that we use for symbols added after HEAD become
&lt;br&gt;CURRENT-9.
&lt;br&gt;&lt;br&gt;I think that you shall change lib/libc/libc_private.h, adding
&lt;br&gt;corresponding definitions for the PJT_CONDATTR_DESTROY/PJT_CONDATTR_INIT
&lt;br&gt;indexes.
&lt;br&gt;&lt;br&gt;Is the patch buildable ?
&lt;br&gt;&lt;br&gt;Interesting question is whether these changes are mergeable to the
&lt;br&gt;stable branch. Possibly yes, if we declare that rtld/libc/libthr shall
&lt;br&gt;be built from the consistent source snapshot.
&lt;br&gt;&lt;br /&gt; &lt;div class=&quot;small&quot;&gt;&lt;br/&gt;&lt;img src=&quot;http://old.nabble.com/images/icon_attachment.gif&quot; &gt; &lt;strong&gt;attachment0&lt;/strong&gt; (203 bytes) &lt;a href=&quot;http://old.nabble.com/attachment/26542359/0/attachment0&quot; target=&quot;_top&quot;&gt;Download Attachment&lt;/a&gt;&lt;/div&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-PATCH--Add-missing-pthread_condattr_%7Binit%2Cdestroy%7D-stubs-to-libc-tp26538004p26542359.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26542238</id>
	<title>Re: threads/135673: databases/mysql50-server - MySQL query lock-ups on 7.2-RELEASE amd64</title>
	<published>2009-11-27T04:45:03Z</published>
	<updated>2009-11-27T04:45:03Z</updated>
	<author>
		<name>Conor McDermottroe-2</name>
	</author>
	<content type="html">On Tue, Nov 24, 2009 at 04:53:36PM +0100, Attilio Rao wrote:
&lt;br&gt;&amp;gt; My last findings were revealing a sudden zeroing of userland
&lt;br&gt;&amp;gt; structures where a lock was embedded, leaving some waiters on such
&lt;br&gt;&amp;gt; locks stuck in the kernel.
&lt;br&gt;&amp;gt; I think this is a MySQL bug and I feel to suggest you to upgrade to
&lt;br&gt;&amp;gt; newest MySQL versions.
&lt;br&gt;&lt;br&gt;I'll experiment with MySQL 5.1 on our new FreeBSD 8.0 machine and see
&lt;br&gt;if I can trigger the bug on that.
&lt;br&gt;&lt;br&gt;Is there anything specific I can do to gather information for you when
&lt;br&gt;I'm testing that?
&lt;br&gt;&lt;br&gt;-Conor
&lt;br&gt;_______________________________________________
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26542238&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads@...&lt;/a&gt; mailing list
&lt;br&gt;&lt;a href=&quot;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&lt;/a&gt;&lt;br&gt;To unsubscribe, send any mail to &amp;quot;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26542238&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads-unsubscribe@...&lt;/a&gt;&amp;quot;
&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Re%3A-threads-135673%3A-databases-mysql50-server---MySQL-query-lock-ups-on-7.2-RELEASE-amd64-tp26498329p26542238.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26538004</id>
	<title>[PATCH] Add missing pthread_condattr_{init,destroy} stubs to libc</title>
	<published>2009-11-26T21:15:18Z</published>
	<updated>2009-11-26T21:15:18Z</updated>
	<author>
		<name>marcus-11</name>
	</author>
	<content type="html">I would like permission to commit this patch which adds missing
&lt;br&gt;pthread_condattr_{init,destroy} symbols to libc. &amp;nbsp;I think I did the
&lt;br&gt;symbol addition correctly (and it seems to work). &amp;nbsp;Without this, the
&lt;br&gt;weak symbols added in the libpthread-stubs port conflict with those in
&lt;br&gt;libthr, and applications with use these symbols can crash.
&lt;br&gt;&lt;br&gt;I have temporarily hacked libpthread-stubs to fix this, but I really
&lt;br&gt;feel these stubs should be added to libc. &amp;nbsp;I've also copied kib as he
&lt;br&gt;has been kind enough to review my work in the past. &amp;nbsp;Thanks.
&lt;br&gt;&lt;br&gt;&lt;a href=&quot;http://www.marcuscom.com/downloads/stubs.diff&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.marcuscom.com/downloads/stubs.diff&lt;/a&gt;&lt;br&gt;&lt;br&gt;Joe
&lt;br&gt;-- 
&lt;br&gt;Joe Marcus Clarke
&lt;br&gt;FreeBSD GNOME Team &amp;nbsp; &amp;nbsp; &amp;nbsp;:: &amp;nbsp; &amp;nbsp; &amp;nbsp;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26538004&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;gnome@...&lt;/a&gt;
&lt;br&gt;FreeNode / #freebsd-gnome
&lt;br&gt;&lt;a href=&quot;http://www.FreeBSD.org/gnome&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.FreeBSD.org/gnome&lt;/a&gt;&lt;br&gt;&lt;br /&gt; &lt;div class=&quot;small&quot;&gt;&lt;br/&gt;&lt;img src=&quot;http://old.nabble.com/images/icon_attachment.gif&quot; &gt; &lt;strong&gt;signature.asc&lt;/strong&gt; (203 bytes) &lt;a href=&quot;http://old.nabble.com/attachment/26538004/0/signature.asc&quot; target=&quot;_top&quot;&gt;Download Attachment&lt;/a&gt;&lt;/div&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/-PATCH--Add-missing-pthread_condattr_%7Binit%2Cdestroy%7D-stubs-to-libc-tp26538004p26538004.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26498404</id>
	<title>Re: threads/135673: databases/mysql50-server - MySQL query lock-ups on 7.2-RELEASE amd64</title>
	<published>2009-11-24T07:53:36Z</published>
	<updated>2009-11-24T07:53:36Z</updated>
	<author>
		<name>Attilio Rao-2</name>
	</author>
	<content type="html">2009/11/24 Conor McDermottroe &amp;lt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26498404&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;ports@...&lt;/a&gt;&amp;gt;:
&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; The following reply was made to PR threads/135673; it has been noted by GNATS.
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; From: Conor McDermottroe &amp;lt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26498404&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;ports@...&lt;/a&gt;&amp;gt;
&lt;br&gt;&amp;gt; To: &lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26498404&amp;i=2&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;bug-followup@...&lt;/a&gt;, &lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26498404&amp;i=3&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-bugs@...&lt;/a&gt;
&lt;br&gt;&amp;gt; Cc:
&lt;br&gt;&amp;gt; Subject: Re: threads/135673: databases/mysql50-server - MySQL query
&lt;br&gt;&amp;gt; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp;lock-ups on 7.2-RELEASE amd64
&lt;br&gt;&amp;gt; Date: Tue, 24 Nov 2009 15:19:38 +0000
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; &amp;nbsp;Thanks very much for the patch, we were running into it as well. The good
&lt;br&gt;&amp;gt; &amp;nbsp;news is that it improves the situation quite a bit. The bad news is that
&lt;br&gt;&amp;gt; &amp;nbsp;it does not appear to cure the problem entirely. Under heavy load we see
&lt;br&gt;&amp;gt; &amp;nbsp;the same problem re-occurring.
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; &amp;nbsp;We'll be bringing up another machine with 8.0 in the coming weeks and I
&lt;br&gt;&amp;gt; &amp;nbsp;hope to test it then.
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; &amp;nbsp;We're currently avoiding this bug by under-loading the 7.2 machine and
&lt;br&gt;&amp;gt; &amp;nbsp;handling more queries on a different 7.0 machine. Is there any
&lt;br&gt;&amp;gt; &amp;nbsp;information I can provide which would help diagnose this bug further?
&lt;/div&gt;&lt;br&gt;My last findings were revealing a sudden zeroing of userland
&lt;br&gt;structures where a lock was embedded, leaving some waiters on such
&lt;br&gt;locks stuck in the kernel.
&lt;br&gt;I think this is a MySQL bug and I feel to suggest you to upgrade to
&lt;br&gt;newest MySQL versions.
&lt;br&gt;&lt;br&gt;Attilio
&lt;br&gt;&lt;br&gt;&lt;br&gt;-- 
&lt;br&gt;Peace can only be achieved by understanding - A. Einstein
&lt;br&gt;_______________________________________________
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26498404&amp;i=4&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads@...&lt;/a&gt; mailing list
&lt;br&gt;&lt;a href=&quot;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&lt;/a&gt;&lt;br&gt;To unsubscribe, send any mail to &amp;quot;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26498404&amp;i=5&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads-unsubscribe@...&lt;/a&gt;&amp;quot;
&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Re%3A-threads-135673%3A-databases-mysql50-server---MySQL-query-lock-ups-on-7.2-RELEASE-amd64-tp26498329p26498404.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26498329</id>
	<title>Re: threads/135673: databases/mysql50-server - MySQL query lock-ups on 7.2-RELEASE amd64</title>
	<published>2009-11-24T07:50:03Z</published>
	<updated>2009-11-24T07:50:03Z</updated>
	<author>
		<name>Conor McDermottroe-2</name>
	</author>
	<content type="html">The following reply was made to PR threads/135673; it has been noted by GNATS.
&lt;br&gt;&lt;br&gt;From: Conor McDermottroe &amp;lt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26498329&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;ports@...&lt;/a&gt;&amp;gt;
&lt;br&gt;To: &lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26498329&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;bug-followup@...&lt;/a&gt;, &lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26498329&amp;i=2&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-bugs@...&lt;/a&gt;
&lt;br&gt;Cc: &amp;nbsp;
&lt;br&gt;Subject: Re: threads/135673: databases/mysql50-server - MySQL query
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; lock-ups on 7.2-RELEASE amd64
&lt;br&gt;Date: Tue, 24 Nov 2009 15:19:38 +0000
&lt;br&gt;&lt;br&gt;&amp;nbsp;Thanks very much for the patch, we were running into it as well. The good
&lt;br&gt;&amp;nbsp;news is that it improves the situation quite a bit. The bad news is that
&lt;br&gt;&amp;nbsp;it does not appear to cure the problem entirely. Under heavy load we see
&lt;br&gt;&amp;nbsp;the same problem re-occurring.
&lt;br&gt;&amp;nbsp;
&lt;br&gt;&amp;nbsp;We'll be bringing up another machine with 8.0 in the coming weeks and I
&lt;br&gt;&amp;nbsp;hope to test it then.
&lt;br&gt;&amp;nbsp;
&lt;br&gt;&amp;nbsp;We're currently avoiding this bug by under-loading the 7.2 machine and
&lt;br&gt;&amp;nbsp;handling more queries on a different 7.0 machine. Is there any
&lt;br&gt;&amp;nbsp;information I can provide which would help diagnose this bug further?
&lt;br&gt;_______________________________________________
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26498329&amp;i=3&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads@...&lt;/a&gt; mailing list
&lt;br&gt;&lt;a href=&quot;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&lt;/a&gt;&lt;br&gt;To unsubscribe, send any mail to &amp;quot;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26498329&amp;i=4&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads-unsubscribe@...&lt;/a&gt;&amp;quot;
&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Re%3A-threads-135673%3A-databases-mysql50-server---MySQL-query-lock-ups-on-7.2-RELEASE-amd64-tp26498329p26498329.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26476117</id>
	<title>Current problem reports assigned to freebsd-threads@FreeBSD.org</title>
	<published>2009-11-23T03:07:05Z</published>
	<updated>2009-11-23T03:07:05Z</updated>
	<author>
		<name>FreeBSD bugmaster</name>
	</author>
	<content type="html">Note: to view an individual PR, use:
&lt;br&gt;&amp;nbsp; &lt;a href=&quot;http://www.freebsd.org/cgi/query-pr.cgi?pr=(number&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.freebsd.org/cgi/query-pr.cgi?pr=(number&lt;/a&gt;).
&lt;br&gt;&lt;br&gt;The following is a listing of current problems submitted by FreeBSD users.
&lt;br&gt;These represent problem reports covering all versions including
&lt;br&gt;experimental development code and obsolete releases.
&lt;br&gt;&lt;br&gt;&lt;br&gt;S Tracker &amp;nbsp; &amp;nbsp; &amp;nbsp;Resp. &amp;nbsp; &amp;nbsp; &amp;nbsp;Description
&lt;br&gt;--------------------------------------------------------------------------------
&lt;br&gt;o threa/136345 threads &amp;nbsp; &amp;nbsp;Recursive read rwlocks in thread A cause deadlock with
&lt;br&gt;o threa/135673 threads &amp;nbsp; &amp;nbsp;databases/mysql50-server - MySQL query lock-ups on 7.2
&lt;br&gt;p threa/135462 threads &amp;nbsp; &amp;nbsp;[PATCH] _thread_cleanupspecific() doesn't handle delet
&lt;br&gt;o threa/133734 threads &amp;nbsp; &amp;nbsp;32 bit libthr failing pthread_create()
&lt;br&gt;o threa/128922 threads &amp;nbsp; &amp;nbsp;threads hang with xorg running
&lt;br&gt;o threa/127225 threads &amp;nbsp; &amp;nbsp;bug in lib/libthr/thread/thr_init.c
&lt;br&gt;o threa/122923 threads &amp;nbsp; &amp;nbsp;'nice' does not prevent background process from steali
&lt;br&gt;o threa/121336 threads &amp;nbsp; &amp;nbsp;lang/neko threading ok on UP, broken on SMP (FreeBSD 7
&lt;br&gt;o threa/118715 threads &amp;nbsp; &amp;nbsp;kse problem
&lt;br&gt;o threa/116668 threads &amp;nbsp; &amp;nbsp;can no longer use jdk15 with libthr on -stable SMP
&lt;br&gt;o threa/116181 threads &amp;nbsp; &amp;nbsp;/dev/io-related io access permissions are not propagat
&lt;br&gt;o threa/115211 threads &amp;nbsp; &amp;nbsp;pthread_atfork misbehaves in initial thread
&lt;br&gt;o threa/110636 threads &amp;nbsp; &amp;nbsp;[request] gdb(1): using gdb with multi thread applicat
&lt;br&gt;o threa/110306 threads &amp;nbsp; &amp;nbsp;apache 2.0 segmentation violation when calling gethost
&lt;br&gt;o threa/103975 threads &amp;nbsp; &amp;nbsp;Implicit loading/unloading of libpthread.so may crash 
&lt;br&gt;o threa/101323 threads &amp;nbsp; &amp;nbsp;[patch] fork(2) in threaded programs broken.
&lt;br&gt;s threa/100815 threads &amp;nbsp; &amp;nbsp;FBSD 5.5 broke nanosleep in libc_r
&lt;br&gt;s threa/94467 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;send(), sendto() and sendmsg() are not correct in libc
&lt;br&gt;s threa/84483 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;problems with devel/nspr and -lc_r on 4.x
&lt;br&gt;o threa/83914 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;[libc] popen() doesn't work in static threaded program
&lt;br&gt;o threa/80992 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;abort() sometimes not caught by gdb depending on threa
&lt;br&gt;o threa/80435 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;panic on high loads
&lt;br&gt;o threa/79887 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;[patch] freopen() isn't thread-safe
&lt;br&gt;o threa/79683 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;svctcp_create() fails if multiple threads call at the 
&lt;br&gt;s threa/76694 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;fork cause hang in dup()/close() function in child (-l
&lt;br&gt;s threa/76690 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;fork hang in child for -lc_r
&lt;br&gt;o threa/75374 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;pthread_kill() ignores SA_SIGINFO flag
&lt;br&gt;o threa/75273 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;FBSD 5.3 &amp;nbsp;libpthread (KSE) bug
&lt;br&gt;o threa/72953 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST
&lt;br&gt;o threa/70975 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;[sysvipc] unexpected and unreliable behaviour when usi
&lt;br&gt;s threa/69020 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;pthreads library leaks _gc_mutex
&lt;br&gt;s threa/49087 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;Signals lost in programs linked with libc_r
&lt;br&gt;s threa/48856 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;Setting SIGCHLD to SIG_IGN still leaves zombies under 
&lt;br&gt;s threa/40671 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;pthread_cancel doesn't remove thread from condition qu
&lt;br&gt;s threa/39922 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;[threads] [patch] Threaded applications executed with 
&lt;br&gt;s threa/37676 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra
&lt;br&gt;s threa/34536 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;accept() blocks other threads
&lt;br&gt;s threa/32295 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;[libc_r] [patch] pthread(3) dont dequeue signals
&lt;br&gt;s threa/30464 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;pthread mutex attributes -- pshared
&lt;br&gt;s threa/24632 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;libc_r delicate deviation from libc in handling SIGCHL
&lt;br&gt;s threa/24472 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o
&lt;br&gt;&lt;br&gt;41 problems total.
&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26476117&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads@...&lt;/a&gt; mailing list
&lt;br&gt;&lt;a href=&quot;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&lt;/a&gt;&lt;br&gt;To unsubscribe, send any mail to &amp;quot;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26476117&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads-unsubscribe@...&lt;/a&gt;&amp;quot;
&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Current-problem-reports-assigned-to-freebsd-threads%40FreeBSD.org-tp26476117p26476117.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26434048</id>
	<title>Re: Using pthread_once() in libc</title>
	<published>2009-11-19T13:02:06Z</published>
	<updated>2009-11-19T13:02:06Z</updated>
	<author>
		<name>Daniel Eischen</name>
	</author>
	<content type="html">On Thu, 19 Nov 2009, John Baldwin wrote:
&lt;br&gt;&lt;br&gt;&amp;gt; On Thursday 19 November 2009 3:00:19 pm Daniel Eischen wrote:
&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; I guess that works.
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; Ok, after a few rounds with the compiler the attached patch actually finished
&lt;br&gt;&amp;gt; a buildworld. &amp;nbsp;Do you have any feedback on it?
&lt;br&gt;&lt;br&gt;That looks fine to me :-)
&lt;br&gt;&lt;br&gt;-- 
&lt;br&gt;DE
&lt;br&gt;_______________________________________________
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26434048&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads@...&lt;/a&gt; mailing list
&lt;br&gt;&lt;a href=&quot;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&lt;/a&gt;&lt;br&gt;To unsubscribe, send any mail to &amp;quot;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26434048&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads-unsubscribe@...&lt;/a&gt;&amp;quot;
&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Using-pthread_once%28%29-in-libc-tp26428253p26434048.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26433724</id>
	<title>Re: Using pthread_once() in libc</title>
	<published>2009-11-19T12:39:47Z</published>
	<updated>2009-11-19T12:39:47Z</updated>
	<author>
		<name>John Baldwin</name>
	</author>
	<content type="html">On Thursday 19 November 2009 3:00:19 pm Daniel Eischen wrote:
&lt;div class='shrinkable-quote'&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; On Thu, 19 Nov 2009, John Baldwin wrote:
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; On Thursday 19 November 2009 12:09:33 pm Daniel Eischen wrote:
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt; On Thu, 19 Nov 2009, John Baldwin wrote:
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; On Thursday 19 November 2009 11:48:54 am Daniel Eischen wrote:
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt; On Thu, 19 Nov 2009, John Baldwin wrote:
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; I would like to provide a pthread_once()-like facility in libc that library
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; bits can use to initialize data safely rather than trying to home-roll their
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; own variants (see the recent commit to stdtime in libc). &amp;nbsp;Ideally what I
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; would like to do is have libc use the &amp;quot;real&amp;quot; pthread_once() when libthr is
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; linked in and fall back to a simple stub without libthr linked in. &amp;nbsp;I know we
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; already do something like this for _spinlock() and friends. &amp;nbsp;My question is
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; what is the most correct way to do this? &amp;nbsp;Should libc grow a new _once()
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; symbol ala _spinlock() that is a weak symbol to a stub version and
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; pthread_once() in thr_once.c would override that, or should there be a
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; _pthread_once() in libc that is a stub in place of the current stub_zero? &amp;nbsp;I
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; noticed a comment in thr_spinlock.c saying the spinlock stuff is kept for
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; backwards compat. &amp;nbsp;Does this mean that for the future we would like to expose
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; pthread symbols directly in libc? &amp;nbsp;Meaning would we rather have libc export a
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; pthread_once() and that ideally libc would be using pthread_mutex_lock/unlock
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; instead of _spinlock/unlock?
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt; pthread_once() is already a stub in libc that gets overloaded with the
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt; real thing when libthr is linked. &amp;nbsp;See libc/gen/_pthread_stubs.c.
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt; Isn't that what you want or does it not serve your purpose?
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; Hmm, the libc stub will never run the init routine. &amp;nbsp;I would like to do
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; something like this:
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt; Well, I suppose you could do that. &amp;nbsp;But what happens if libthr gets
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt; dlopen()'d and your once function needs to initialize a mutex or
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt; something that can only be properly done by a real threads library?
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt; Can we envision a scenario where that would be a problem?
&lt;br&gt;&amp;gt; &amp;gt;
&lt;br&gt;&amp;gt; &amp;gt; Hmmm, so I guess __is_threaded is how the dlopen() case is handled now for
&lt;br&gt;&amp;gt; &amp;gt; mutex lock/unlock as that avoids resolving the symbol until pthread_create()
&lt;br&gt;&amp;gt; &amp;gt; has been invoked? &amp;nbsp;I guess then we could take an approach that works
&lt;br&gt;&amp;gt; &amp;gt; something like this:
&lt;br&gt;&amp;gt; &amp;gt;
&lt;br&gt;&amp;gt; &amp;gt; /* libc-internal function */
&lt;br&gt;&amp;gt; &amp;gt; int
&lt;br&gt;&amp;gt; &amp;gt; _once(pthread_once_t *once_control, void (*init_routine)(void))
&lt;br&gt;&amp;gt; &amp;gt; {
&lt;br&gt;&amp;gt; &amp;gt;
&lt;br&gt;&amp;gt; &amp;gt; 	if (__is_threaded)
&lt;br&gt;&amp;gt; &amp;gt; 		return (_pthread_once(once_control, init_routine));
&lt;br&gt;&amp;gt; &amp;gt;
&lt;br&gt;&amp;gt; &amp;gt; 	return (_stub_once(once_control, init_routine));
&lt;br&gt;&amp;gt; &amp;gt; }
&lt;br&gt;&amp;gt; &amp;gt;
&lt;br&gt;&amp;gt; &amp;gt; It is probably still a good idea to have the stub_once() patch I think so
&lt;br&gt;&amp;gt; &amp;gt; that pthread_once() DTRT in a single-threaded program.
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; I guess that works.
&lt;/div&gt;&lt;/div&gt;Ok, after a few rounds with the compiler the attached patch actually finished
&lt;br&gt;a buildworld. &amp;nbsp;Do you have any feedback on it?
&lt;br&gt;&lt;br&gt;-- 
&lt;br&gt;John Baldwin
&lt;br&gt;&lt;br /&gt;&lt;tt&gt;[stdtime.patch]&lt;/tt&gt;&lt;br /&gt;&lt;hr align=&quot;left&quot; width=&quot;300&quot; /&gt;&lt;tt&gt;Index: gen/Makefile.inc
&lt;br&gt;===================================================================
&lt;br&gt;--- gen/Makefile.inc	(revision 199529)
&lt;br&gt;+++ gen/Makefile.inc	(working copy)
&lt;br&gt;@@ -5,7 +5,7 @@
&lt;br&gt;&amp;nbsp;.PATH: ${.CURDIR}/${MACHINE_ARCH}/gen ${.CURDIR}/gen
&lt;br&gt;&amp;nbsp;
&lt;br&gt;&amp;nbsp;SRCS+= &amp;nbsp;__getosreldate.c __xuname.c \
&lt;br&gt;-	_pthread_stubs.c _rand48.c _spinlock_stub.c _thread_init.c \
&lt;br&gt;+	_once_stub.c _pthread_stubs.c _rand48.c _spinlock_stub.c _thread_init.c \
&lt;br&gt;&amp;nbsp;	alarm.c arc4random.c assert.c basename.c check_utility_compat.c \
&lt;br&gt;&amp;nbsp;	clock.c closedir.c confstr.c \
&lt;br&gt;&amp;nbsp;	crypt.c ctermid.c daemon.c devname.c dirname.c disklabel.c \
&lt;br&gt;Index: gen/_once_stub.c
&lt;br&gt;===================================================================
&lt;br&gt;--- gen/_once_stub.c	(revision 0)
&lt;br&gt;+++ gen/_once_stub.c	(revision 0)
&lt;br&gt;@@ -0,0 +1,44 @@
&lt;br&gt;+/*-
&lt;br&gt;+ * XXX: Copyright
&lt;br&gt;+ */
&lt;br&gt;+
&lt;br&gt;+#include &amp;lt;sys/cdefs.h&amp;gt;
&lt;br&gt;+__FBSDID(&amp;quot;$FreeBSD$&amp;quot;);
&lt;br&gt;+
&lt;br&gt;+#include &amp;quot;namespace.h&amp;quot;
&lt;br&gt;+#include &amp;lt;pthread.h&amp;gt;
&lt;br&gt;+#include &amp;quot;un-namespace.h&amp;quot;
&lt;br&gt;+#include &amp;quot;libc_private.h&amp;quot;
&lt;br&gt;+
&lt;br&gt;+/*
&lt;br&gt;+ * This implements pthread_once() for the single-threaded case. &amp;nbsp;It is
&lt;br&gt;+ * non-static so that it can be used by _pthread_stubs.c.
&lt;br&gt;+ */
&lt;br&gt;+int
&lt;br&gt;+_libc_once(pthread_once_t *once_control, void (*init_routine)(void))
&lt;br&gt;+{
&lt;br&gt;+
&lt;br&gt;+	if (once_control-&amp;gt;state == PTHREAD_NEEDS_INIT)
&lt;br&gt;+		return (0);
&lt;br&gt;+	init_routine();
&lt;br&gt;+	once_control-&amp;gt;state = PTHREAD_DONE_INIT;
&lt;br&gt;+	return (0);
&lt;br&gt;+}
&lt;br&gt;+
&lt;br&gt;+/*
&lt;br&gt;+ * This is the internal interface provided to libc. &amp;nbsp;It will use
&lt;br&gt;+ * pthread_once() from the threading library in a multi-threaded
&lt;br&gt;+ * process and _libc_once() for a single-threaded library. &amp;nbsp;Because
&lt;br&gt;+ * _libc_once() uses the same ABI for the values in the pthread_once_t
&lt;br&gt;+ * structure as the threading library, it is safe for a process to
&lt;br&gt;+ * switch from _libc_once() to pthread_once() when threading is
&lt;br&gt;+ * enabled.
&lt;br&gt;+ */
&lt;br&gt;+int
&lt;br&gt;+_once(pthread_once_t *once_control, void (*init_routine)(void))
&lt;br&gt;+{
&lt;br&gt;+
&lt;br&gt;+	if (__isthreaded)
&lt;br&gt;+		return (_pthread_once(once_control, init_routine));
&lt;br&gt;+	return (_libc_once(once_control, init_routine));
&lt;br&gt;+}
&lt;br&gt;&lt;br&gt;Property changes on: gen/_once_stub.c
&lt;br&gt;___________________________________________________________________
&lt;br&gt;Added: svn:mime-type
&lt;br&gt;&amp;nbsp; &amp;nbsp;+ text/plain
&lt;br&gt;Added: svn:keywords
&lt;br&gt;&amp;nbsp; &amp;nbsp;+ FreeBSD=%H
&lt;br&gt;Added: svn:eol-style
&lt;br&gt;&amp;nbsp; &amp;nbsp;+ native
&lt;br&gt;&lt;br&gt;Index: gen/_pthread_stubs.c
&lt;br&gt;===================================================================
&lt;br&gt;--- gen/_pthread_stubs.c	(revision 199529)
&lt;br&gt;+++ gen/_pthread_stubs.c	(working copy)
&lt;br&gt;@@ -105,7 +105,7 @@
&lt;br&gt;&amp;nbsp;	{PJT_DUAL_ENTRY(stub_zero)}, &amp;nbsp; &amp;nbsp;/* PJT_MUTEX_LOCK */
&lt;br&gt;&amp;nbsp;	{PJT_DUAL_ENTRY(stub_zero)}, &amp;nbsp; &amp;nbsp;/* PJT_MUTEX_TRYLOCK */
&lt;br&gt;&amp;nbsp;	{PJT_DUAL_ENTRY(stub_zero)}, &amp;nbsp; &amp;nbsp;/* PJT_MUTEX_UNLOCK */
&lt;br&gt;-	{PJT_DUAL_ENTRY(stub_zero)}, &amp;nbsp; &amp;nbsp;/* PJT_ONCE */
&lt;br&gt;+	{PJT_DUAL_ENTRY(_libc_once)}, &amp;nbsp; /* PJT_ONCE */
&lt;br&gt;&amp;nbsp;	{PJT_DUAL_ENTRY(stub_zero)}, &amp;nbsp; &amp;nbsp;/* PJT_RWLOCK_DESTROY */
&lt;br&gt;&amp;nbsp;	{PJT_DUAL_ENTRY(stub_zero)}, &amp;nbsp; &amp;nbsp;/* PJT_RWLOCK_INIT */
&lt;br&gt;&amp;nbsp;	{PJT_DUAL_ENTRY(stub_zero)}, &amp;nbsp; &amp;nbsp;/* PJT_RWLOCK_RDLOCK */
&lt;br&gt;Index: stdtime/localtime.c
&lt;br&gt;===================================================================
&lt;br&gt;--- stdtime/localtime.c	(revision 199529)
&lt;br&gt;+++ stdtime/localtime.c	(working copy)
&lt;br&gt;@@ -235,9 +235,8 @@
&lt;br&gt;&amp;nbsp;
&lt;br&gt;&amp;nbsp;static char		lcl_TZname[TZ_STRLEN_MAX + 1];
&lt;br&gt;&amp;nbsp;static int		lcl_is_set;
&lt;br&gt;-static int		gmt_is_set;
&lt;br&gt;+static pthread_once_t	gmt_once = PTHREAD_ONCE_INIT;
&lt;br&gt;&amp;nbsp;static pthread_rwlock_t	lcl_rwlock = PTHREAD_RWLOCK_INITIALIZER;
&lt;br&gt;-static pthread_mutex_t	gmt_mutex = PTHREAD_MUTEX_INITIALIZER;
&lt;br&gt;&amp;nbsp;
&lt;br&gt;&amp;nbsp;char *			tzname[2] = {
&lt;br&gt;&amp;nbsp;	wildabbr,
&lt;br&gt;@@ -1464,6 +1463,17 @@
&lt;br&gt;&amp;nbsp;	return tmp;
&lt;br&gt;&amp;nbsp;}
&lt;br&gt;&amp;nbsp;
&lt;br&gt;+static void
&lt;br&gt;+gmt_init(void)
&lt;br&gt;+{
&lt;br&gt;+
&lt;br&gt;+#ifdef ALL_STATE
&lt;br&gt;+	gmtptr = (struct state *) malloc(sizeof *gmtptr);
&lt;br&gt;+	if (gmtptr != NULL)
&lt;br&gt;+#endif /* defined ALL_STATE */
&lt;br&gt;+		gmtload(gmtptr);
&lt;br&gt;+}
&lt;br&gt;+
&lt;br&gt;&amp;nbsp;/*
&lt;br&gt;&amp;nbsp;** gmtsub is to gmtime as localsub is to localtime.
&lt;br&gt;&amp;nbsp;*/
&lt;br&gt;@@ -1476,16 +1486,7 @@
&lt;br&gt;&amp;nbsp;{
&lt;br&gt;&amp;nbsp;	register struct tm *	result;
&lt;br&gt;&amp;nbsp;
&lt;br&gt;-	_MUTEX_LOCK(&amp;gmt_mutex);
&lt;br&gt;-	if (!gmt_is_set) {
&lt;br&gt;-#ifdef ALL_STATE
&lt;br&gt;-		gmtptr = (struct state *) malloc(sizeof *gmtptr);
&lt;br&gt;-		if (gmtptr != NULL)
&lt;br&gt;-#endif /* defined ALL_STATE */
&lt;br&gt;-			gmtload(gmtptr);
&lt;br&gt;-		gmt_is_set = TRUE;
&lt;br&gt;-	}
&lt;br&gt;-	_MUTEX_UNLOCK(&amp;gmt_mutex);
&lt;br&gt;+	_once(&amp;gmt_once, gmt_init);
&lt;br&gt;&amp;nbsp;	result = timesub(timep, offset, gmtptr, tmp);
&lt;br&gt;&amp;nbsp;#ifdef TM_ZONE
&lt;br&gt;&amp;nbsp;	/*
&lt;br&gt;Index: include/libc_private.h
&lt;br&gt;===================================================================
&lt;br&gt;--- include/libc_private.h	(revision 199529)
&lt;br&gt;+++ include/libc_private.h	(working copy)
&lt;br&gt;@@ -34,6 +34,7 @@
&lt;br&gt;&amp;nbsp;
&lt;br&gt;&amp;nbsp;#ifndef _LIBC_PRIVATE_H_
&lt;br&gt;&amp;nbsp;#define _LIBC_PRIVATE_H_
&lt;br&gt;+#include &amp;lt;sys/_pthreadtypes.h&amp;gt;
&lt;br&gt;&amp;nbsp;
&lt;br&gt;&amp;nbsp;/*
&lt;br&gt;&amp;nbsp; * This global flag is non-zero when a process has created one
&lt;br&gt;@@ -147,6 +148,13 @@
&lt;br&gt;&amp;nbsp;void _init_tls(void);
&lt;br&gt;&amp;nbsp;
&lt;br&gt;&amp;nbsp;/*
&lt;br&gt;+ * Provides pthread_once()-like functionality for both single-threaded and
&lt;br&gt;+ * multithreaded applications.
&lt;br&gt;+ */
&lt;br&gt;+int _once(pthread_once_t *, void (*)(void));
&lt;br&gt;+int _libc_once(pthread_once_t *, void (*)(void));
&lt;br&gt;+
&lt;br&gt;+/*
&lt;br&gt;&amp;nbsp; * Set the TLS thread pointer
&lt;br&gt;&amp;nbsp; */
&lt;br&gt;&amp;nbsp;void _set_tp(void *tp);
&lt;br&gt;&lt;/tt&gt;&lt;hr align=&quot;left&quot; width=&quot;300&quot; /&gt;&lt;br /&gt;_______________________________________________
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26433724&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads@...&lt;/a&gt; mailing list
&lt;br&gt;&lt;a href=&quot;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&lt;/a&gt;&lt;br&gt;To unsubscribe, send any mail to &amp;quot;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26433724&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads-unsubscribe@...&lt;/a&gt;&amp;quot;
&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Using-pthread_once%28%29-in-libc-tp26428253p26433724.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26433111</id>
	<title>Re: Using pthread_once() in libc</title>
	<published>2009-11-19T12:00:19Z</published>
	<updated>2009-11-19T12:00:19Z</updated>
	<author>
		<name>Daniel Eischen</name>
	</author>
	<content type="html">On Thu, 19 Nov 2009, John Baldwin wrote:
&lt;br&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; On Thursday 19 November 2009 12:09:33 pm Daniel Eischen wrote:
&lt;br&gt;&amp;gt;&amp;gt; On Thu, 19 Nov 2009, John Baldwin wrote:
&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; On Thursday 19 November 2009 11:48:54 am Daniel Eischen wrote:
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; On Thu, 19 Nov 2009, John Baldwin wrote:
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; I would like to provide a pthread_once()-like facility in libc that library
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; bits can use to initialize data safely rather than trying to home-roll their
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; own variants (see the recent commit to stdtime in libc). &amp;nbsp;Ideally what I
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; would like to do is have libc use the &amp;quot;real&amp;quot; pthread_once() when libthr is
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; linked in and fall back to a simple stub without libthr linked in. &amp;nbsp;I know we
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; already do something like this for _spinlock() and friends. &amp;nbsp;My question is
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; what is the most correct way to do this? &amp;nbsp;Should libc grow a new _once()
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; symbol ala _spinlock() that is a weak symbol to a stub version and
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; pthread_once() in thr_once.c would override that, or should there be a
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; _pthread_once() in libc that is a stub in place of the current stub_zero? &amp;nbsp;I
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; noticed a comment in thr_spinlock.c saying the spinlock stuff is kept for
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; backwards compat. &amp;nbsp;Does this mean that for the future we would like to expose
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; pthread symbols directly in libc? &amp;nbsp;Meaning would we rather have libc export a
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; pthread_once() and that ideally libc would be using pthread_mutex_lock/unlock
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; instead of _spinlock/unlock?
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; pthread_once() is already a stub in libc that gets overloaded with the
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; real thing when libthr is linked. &amp;nbsp;See libc/gen/_pthread_stubs.c.
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; Isn't that what you want or does it not serve your purpose?
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; Hmm, the libc stub will never run the init routine. &amp;nbsp;I would like to do
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; something like this:
&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; Well, I suppose you could do that. &amp;nbsp;But what happens if libthr gets
&lt;br&gt;&amp;gt;&amp;gt; dlopen()'d and your once function needs to initialize a mutex or
&lt;br&gt;&amp;gt;&amp;gt; something that can only be properly done by a real threads library?
&lt;br&gt;&amp;gt;&amp;gt; Can we envision a scenario where that would be a problem?
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; Hmmm, so I guess __is_threaded is how the dlopen() case is handled now for
&lt;br&gt;&amp;gt; mutex lock/unlock as that avoids resolving the symbol until pthread_create()
&lt;br&gt;&amp;gt; has been invoked? &amp;nbsp;I guess then we could take an approach that works
&lt;br&gt;&amp;gt; something like this:
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; /* libc-internal function */
&lt;br&gt;&amp;gt; int
&lt;br&gt;&amp;gt; _once(pthread_once_t *once_control, void (*init_routine)(void))
&lt;br&gt;&amp;gt; {
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; 	if (__is_threaded)
&lt;br&gt;&amp;gt; 		return (_pthread_once(once_control, init_routine));
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; 	return (_stub_once(once_control, init_routine));
&lt;br&gt;&amp;gt; }
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; It is probably still a good idea to have the stub_once() patch I think so
&lt;br&gt;&amp;gt; that pthread_once() DTRT in a single-threaded program.
&lt;/div&gt;&lt;br&gt;I guess that works.
&lt;br&gt;&lt;br&gt;-- 
&lt;br&gt;DE
&lt;br&gt;_______________________________________________
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26433111&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads@...&lt;/a&gt; mailing list
&lt;br&gt;&lt;a href=&quot;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&lt;/a&gt;&lt;br&gt;To unsubscribe, send any mail to &amp;quot;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26433111&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads-unsubscribe@...&lt;/a&gt;&amp;quot;
&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Using-pthread_once%28%29-in-libc-tp26428253p26433111.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26430939</id>
	<title>Re: Using pthread_once() in libc</title>
	<published>2009-11-19T09:54:50Z</published>
	<updated>2009-11-19T09:54:50Z</updated>
	<author>
		<name>John Baldwin</name>
	</author>
	<content type="html">On Thursday 19 November 2009 12:09:33 pm Daniel Eischen wrote:
&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; On Thu, 19 Nov 2009, John Baldwin wrote:
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; On Thursday 19 November 2009 11:48:54 am Daniel Eischen wrote:
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt; On Thu, 19 Nov 2009, John Baldwin wrote:
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; I would like to provide a pthread_once()-like facility in libc that library
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; bits can use to initialize data safely rather than trying to home-roll their
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; own variants (see the recent commit to stdtime in libc). &amp;nbsp;Ideally what I
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; would like to do is have libc use the &amp;quot;real&amp;quot; pthread_once() when libthr is
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; linked in and fall back to a simple stub without libthr linked in. &amp;nbsp;I know we
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; already do something like this for _spinlock() and friends. &amp;nbsp;My question is
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; what is the most correct way to do this? &amp;nbsp;Should libc grow a new _once()
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; symbol ala _spinlock() that is a weak symbol to a stub version and
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; pthread_once() in thr_once.c would override that, or should there be a
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; _pthread_once() in libc that is a stub in place of the current stub_zero? &amp;nbsp;I
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; noticed a comment in thr_spinlock.c saying the spinlock stuff is kept for
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; backwards compat. &amp;nbsp;Does this mean that for the future we would like to expose
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; pthread symbols directly in libc? &amp;nbsp;Meaning would we rather have libc export a
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; pthread_once() and that ideally libc would be using pthread_mutex_lock/unlock
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;&amp;gt; instead of _spinlock/unlock?
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt;
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt; pthread_once() is already a stub in libc that gets overloaded with the
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt; real thing when libthr is linked. &amp;nbsp;See libc/gen/_pthread_stubs.c.
&lt;br&gt;&amp;gt; &amp;gt;&amp;gt; Isn't that what you want or does it not serve your purpose?
&lt;br&gt;&amp;gt; &amp;gt;
&lt;br&gt;&amp;gt; &amp;gt; Hmm, the libc stub will never run the init routine. &amp;nbsp;I would like to do
&lt;br&gt;&amp;gt; &amp;gt; something like this:
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; Well, I suppose you could do that. &amp;nbsp;But what happens if libthr gets
&lt;br&gt;&amp;gt; dlopen()'d and your once function needs to initialize a mutex or
&lt;br&gt;&amp;gt; something that can only be properly done by a real threads library?
&lt;br&gt;&amp;gt; Can we envision a scenario where that would be a problem?
&lt;/div&gt;&lt;br&gt;Hmmm, so I guess __is_threaded is how the dlopen() case is handled now for
&lt;br&gt;mutex lock/unlock as that avoids resolving the symbol until pthread_create()
&lt;br&gt;has been invoked? &amp;nbsp;I guess then we could take an approach that works
&lt;br&gt;something like this:
&lt;br&gt;&lt;br&gt;/* libc-internal function */
&lt;br&gt;int
&lt;br&gt;_once(pthread_once_t *once_control, void (*init_routine)(void))
&lt;br&gt;{
&lt;br&gt;&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; if (__is_threaded)
&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; return (_pthread_once(once_control, init_routine));
&lt;br&gt;&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; return (_stub_once(once_control, init_routine));
&lt;br&gt;}
&lt;br&gt;&lt;br&gt;It is probably still a good idea to have the stub_once() patch I think so
&lt;br&gt;that pthread_once() DTRT in a single-threaded program.
&lt;br&gt;&lt;br&gt;-- 
&lt;br&gt;John Baldwin
&lt;br&gt;_______________________________________________
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26430939&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads@...&lt;/a&gt; mailing list
&lt;br&gt;&lt;a href=&quot;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&lt;/a&gt;&lt;br&gt;To unsubscribe, send any mail to &amp;quot;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26430939&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads-unsubscribe@...&lt;/a&gt;&amp;quot;
&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Using-pthread_once%28%29-in-libc-tp26428253p26430939.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26430215</id>
	<title>Re: Using pthread_once() in libc</title>
	<published>2009-11-19T09:11:13Z</published>
	<updated>2009-11-19T09:11:13Z</updated>
	<author>
		<name>Daniel Eischen</name>
	</author>
	<content type="html">On Thu, 19 Nov 2009, John Baldwin wrote:
&lt;br&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; On Thursday 19 November 2009 12:02:30 pm John Baldwin wrote:
&lt;br&gt;&amp;gt;&amp;gt; On Thursday 19 November 2009 11:48:54 am Daniel Eischen wrote:
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; On Thu, 19 Nov 2009, John Baldwin wrote:
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; I would like to provide a pthread_once()-like facility in libc that library
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; bits can use to initialize data safely rather than trying to home-roll their
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; own variants (see the recent commit to stdtime in libc). &amp;nbsp;Ideally what I
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; would like to do is have libc use the &amp;quot;real&amp;quot; pthread_once() when libthr is
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; linked in and fall back to a simple stub without libthr linked in. &amp;nbsp;I know we
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; already do something like this for _spinlock() and friends. &amp;nbsp;My question is
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; what is the most correct way to do this? &amp;nbsp;Should libc grow a new _once()
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; symbol ala _spinlock() that is a weak symbol to a stub version and
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; pthread_once() in thr_once.c would override that, or should there be a
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; _pthread_once() in libc that is a stub in place of the current stub_zero? &amp;nbsp;I
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; noticed a comment in thr_spinlock.c saying the spinlock stuff is kept for
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; backwards compat. &amp;nbsp;Does this mean that for the future we would like to expose
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; pthread symbols directly in libc? &amp;nbsp;Meaning would we rather have libc export a
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; pthread_once() and that ideally libc would be using pthread_mutex_lock/unlock
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; instead of _spinlock/unlock?
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; pthread_once() is already a stub in libc that gets overloaded with the
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; real thing when libthr is linked. &amp;nbsp;See libc/gen/_pthread_stubs.c.
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; Isn't that what you want or does it not serve your purpose?
&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; Hmm, the libc stub will never run the init routine. &amp;nbsp;I would like to do
&lt;br&gt;&amp;gt;&amp;gt; something like this:
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; Perhaps this would work to fix pthread_once:
&lt;/div&gt;&lt;br&gt;No objection here. &amp;nbsp;Still trying to figure out if that could potentially
&lt;br&gt;cause a problem with a dlopen()'d libthr.
&lt;br&gt;&lt;br&gt;-- 
&lt;br&gt;DE
&lt;br&gt;_______________________________________________
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26430215&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads@...&lt;/a&gt; mailing list
&lt;br&gt;&lt;a href=&quot;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&lt;/a&gt;&lt;br&gt;To unsubscribe, send any mail to &amp;quot;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26430215&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads-unsubscribe@...&lt;/a&gt;&amp;quot;
&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Using-pthread_once%28%29-in-libc-tp26428253p26430215.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26430170</id>
	<title>Re: Using pthread_once() in libc</title>
	<published>2009-11-19T09:09:33Z</published>
	<updated>2009-11-19T09:09:33Z</updated>
	<author>
		<name>Daniel Eischen</name>
	</author>
	<content type="html">On Thu, 19 Nov 2009, John Baldwin wrote:
&lt;br&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; On Thursday 19 November 2009 11:48:54 am Daniel Eischen wrote:
&lt;br&gt;&amp;gt;&amp;gt; On Thu, 19 Nov 2009, John Baldwin wrote:
&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; I would like to provide a pthread_once()-like facility in libc that library
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; bits can use to initialize data safely rather than trying to home-roll their
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; own variants (see the recent commit to stdtime in libc). &amp;nbsp;Ideally what I
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; would like to do is have libc use the &amp;quot;real&amp;quot; pthread_once() when libthr is
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; linked in and fall back to a simple stub without libthr linked in. &amp;nbsp;I know we
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; already do something like this for _spinlock() and friends. &amp;nbsp;My question is
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; what is the most correct way to do this? &amp;nbsp;Should libc grow a new _once()
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; symbol ala _spinlock() that is a weak symbol to a stub version and
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; pthread_once() in thr_once.c would override that, or should there be a
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; _pthread_once() in libc that is a stub in place of the current stub_zero? &amp;nbsp;I
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; noticed a comment in thr_spinlock.c saying the spinlock stuff is kept for
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; backwards compat. &amp;nbsp;Does this mean that for the future we would like to expose
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; pthread symbols directly in libc? &amp;nbsp;Meaning would we rather have libc export a
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; pthread_once() and that ideally libc would be using pthread_mutex_lock/unlock
&lt;br&gt;&amp;gt;&amp;gt;&amp;gt; instead of _spinlock/unlock?
&lt;br&gt;&amp;gt;&amp;gt;
&lt;br&gt;&amp;gt;&amp;gt; pthread_once() is already a stub in libc that gets overloaded with the
&lt;br&gt;&amp;gt;&amp;gt; real thing when libthr is linked. &amp;nbsp;See libc/gen/_pthread_stubs.c.
&lt;br&gt;&amp;gt;&amp;gt; Isn't that what you want or does it not serve your purpose?
&lt;br&gt;&amp;gt;
&lt;br&gt;&amp;gt; Hmm, the libc stub will never run the init routine. &amp;nbsp;I would like to do
&lt;br&gt;&amp;gt; something like this:
&lt;/div&gt;&lt;br&gt;Well, I suppose you could do that. &amp;nbsp;But what happens if libthr gets
&lt;br&gt;dlopen()'d and your once function needs to initialize a mutex or
&lt;br&gt;something that can only be properly done by a real threads library?
&lt;br&gt;Can we envision a scenario where that would be a problem?
&lt;br&gt;&lt;br&gt;-- 
&lt;br&gt;DE
&lt;br&gt;_______________________________________________
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26430170&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads@...&lt;/a&gt; mailing list
&lt;br&gt;&lt;a href=&quot;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&lt;/a&gt;&lt;br&gt;To unsubscribe, send any mail to &amp;quot;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26430170&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads-unsubscribe@...&lt;/a&gt;&amp;quot;
&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Using-pthread_once%28%29-in-libc-tp26428253p26430170.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26430126</id>
	<title>Re: Using pthread_once() in libc</title>
	<published>2009-11-19T09:06:40Z</published>
	<updated>2009-11-19T09:06:40Z</updated>
	<author>
		<name>John Baldwin</name>
	</author>
	<content type="html">On Thursday 19 November 2009 12:02:30 pm John Baldwin wrote:
&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; On Thursday 19 November 2009 11:48:54 am Daniel Eischen wrote:
&lt;br&gt;&amp;gt; &amp;gt; On Thu, 19 Nov 2009, John Baldwin wrote:
&lt;br&gt;&amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; I would like to provide a pthread_once()-like facility in libc that library
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; bits can use to initialize data safely rather than trying to home-roll their
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; own variants (see the recent commit to stdtime in libc). &amp;nbsp;Ideally what I
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; would like to do is have libc use the &amp;quot;real&amp;quot; pthread_once() when libthr is
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; linked in and fall back to a simple stub without libthr linked in. &amp;nbsp;I know we
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; already do something like this for _spinlock() and friends. &amp;nbsp;My question is
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; what is the most correct way to do this? &amp;nbsp;Should libc grow a new _once()
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; symbol ala _spinlock() that is a weak symbol to a stub version and
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; pthread_once() in thr_once.c would override that, or should there be a
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; _pthread_once() in libc that is a stub in place of the current stub_zero? &amp;nbsp;I
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; noticed a comment in thr_spinlock.c saying the spinlock stuff is kept for
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; backwards compat. &amp;nbsp;Does this mean that for the future we would like to expose
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; pthread symbols directly in libc? &amp;nbsp;Meaning would we rather have libc export a
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; pthread_once() and that ideally libc would be using pthread_mutex_lock/unlock
&lt;br&gt;&amp;gt; &amp;gt; &amp;gt; instead of _spinlock/unlock?
&lt;br&gt;&amp;gt; &amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; pthread_once() is already a stub in libc that gets overloaded with the
&lt;br&gt;&amp;gt; &amp;gt; real thing when libthr is linked. &amp;nbsp;See libc/gen/_pthread_stubs.c.
&lt;br&gt;&amp;gt; &amp;gt; Isn't that what you want or does it not serve your purpose?
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; Hmm, the libc stub will never run the init routine. &amp;nbsp;I would like to do
&lt;br&gt;&amp;gt; something like this:
&lt;/div&gt;&lt;br&gt;Perhaps this would work to fix pthread_once:
&lt;br&gt;&lt;br&gt;Index: gen/_pthread_stubs.c
&lt;br&gt;===================================================================
&lt;br&gt;--- gen/_pthread_stubs.c	(revision 199529)
&lt;br&gt;+++ gen/_pthread_stubs.c	(working copy)
&lt;br&gt;@@ -51,6 +51,8 @@
&lt;br&gt;&amp;nbsp;
&lt;br&gt;&amp;nbsp;static int		stub_main(void);
&lt;br&gt;&amp;nbsp;static void 		*stub_null(void);
&lt;br&gt;+static int		stub_once(pthread_once_t *once_control,
&lt;br&gt;+			 &amp;nbsp; &amp;nbsp;void (*init_routine)(void));
&lt;br&gt;&amp;nbsp;static struct pthread	*stub_self(void);
&lt;br&gt;&amp;nbsp;static int		stub_zero(void);
&lt;br&gt;&amp;nbsp;static int		stub_true(void);
&lt;br&gt;@@ -105,7 +107,7 @@
&lt;br&gt;&amp;nbsp;	{PJT_DUAL_ENTRY(stub_zero)}, &amp;nbsp; &amp;nbsp;/* PJT_MUTEX_LOCK */
&lt;br&gt;&amp;nbsp;	{PJT_DUAL_ENTRY(stub_zero)}, &amp;nbsp; &amp;nbsp;/* PJT_MUTEX_TRYLOCK */
&lt;br&gt;&amp;nbsp;	{PJT_DUAL_ENTRY(stub_zero)}, &amp;nbsp; &amp;nbsp;/* PJT_MUTEX_UNLOCK */
&lt;br&gt;-	{PJT_DUAL_ENTRY(stub_zero)}, &amp;nbsp; &amp;nbsp;/* PJT_ONCE */
&lt;br&gt;+	{PJT_DUAL_ENTRY(stub_once)}, &amp;nbsp; &amp;nbsp;/* PJT_ONCE */
&lt;br&gt;&amp;nbsp;	{PJT_DUAL_ENTRY(stub_zero)}, &amp;nbsp; &amp;nbsp;/* PJT_RWLOCK_DESTROY */
&lt;br&gt;&amp;nbsp;	{PJT_DUAL_ENTRY(stub_zero)}, &amp;nbsp; &amp;nbsp;/* PJT_RWLOCK_INIT */
&lt;br&gt;&amp;nbsp;	{PJT_DUAL_ENTRY(stub_zero)}, &amp;nbsp; &amp;nbsp;/* PJT_RWLOCK_RDLOCK */
&lt;br&gt;@@ -301,3 +303,14 @@
&lt;br&gt;&amp;nbsp;{
&lt;br&gt;&amp;nbsp;	exit(0);
&lt;br&gt;&amp;nbsp;}
&lt;br&gt;+
&lt;br&gt;+static int
&lt;br&gt;+stub_once(pthread_once_t *once_control, void (*init_routine)(void))
&lt;br&gt;+{
&lt;br&gt;+
&lt;br&gt;+	if (once_control-&amp;gt;state == ONCE_DONE)
&lt;br&gt;+		return (0);
&lt;br&gt;+	init_routine();
&lt;br&gt;+	once_control-&amp;gt;state = ONCE_DONE;
&lt;br&gt;+	return (0);
&lt;br&gt;+}
&lt;br&gt;&lt;br&gt;-- 
&lt;br&gt;John Baldwin
&lt;br&gt;_______________________________________________
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26430126&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads@...&lt;/a&gt; mailing list
&lt;br&gt;&lt;a href=&quot;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&lt;/a&gt;&lt;br&gt;To unsubscribe, send any mail to &amp;quot;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26430126&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads-unsubscribe@...&lt;/a&gt;&amp;quot;
&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Using-pthread_once%28%29-in-libc-tp26428253p26430126.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26430071</id>
	<title>Re: Using pthread_once() in libc</title>
	<published>2009-11-19T09:02:30Z</published>
	<updated>2009-11-19T09:02:30Z</updated>
	<author>
		<name>John Baldwin</name>
	</author>
	<content type="html">On Thursday 19 November 2009 11:48:54 am Daniel Eischen wrote:
&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; On Thu, 19 Nov 2009, John Baldwin wrote:
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; &amp;gt; I would like to provide a pthread_once()-like facility in libc that library
&lt;br&gt;&amp;gt; &amp;gt; bits can use to initialize data safely rather than trying to home-roll their
&lt;br&gt;&amp;gt; &amp;gt; own variants (see the recent commit to stdtime in libc). &amp;nbsp;Ideally what I
&lt;br&gt;&amp;gt; &amp;gt; would like to do is have libc use the &amp;quot;real&amp;quot; pthread_once() when libthr is
&lt;br&gt;&amp;gt; &amp;gt; linked in and fall back to a simple stub without libthr linked in. &amp;nbsp;I know we
&lt;br&gt;&amp;gt; &amp;gt; already do something like this for _spinlock() and friends. &amp;nbsp;My question is
&lt;br&gt;&amp;gt; &amp;gt; what is the most correct way to do this? &amp;nbsp;Should libc grow a new _once()
&lt;br&gt;&amp;gt; &amp;gt; symbol ala _spinlock() that is a weak symbol to a stub version and
&lt;br&gt;&amp;gt; &amp;gt; pthread_once() in thr_once.c would override that, or should there be a
&lt;br&gt;&amp;gt; &amp;gt; _pthread_once() in libc that is a stub in place of the current stub_zero? &amp;nbsp;I
&lt;br&gt;&amp;gt; &amp;gt; noticed a comment in thr_spinlock.c saying the spinlock stuff is kept for
&lt;br&gt;&amp;gt; &amp;gt; backwards compat. &amp;nbsp;Does this mean that for the future we would like to expose
&lt;br&gt;&amp;gt; &amp;gt; pthread symbols directly in libc? &amp;nbsp;Meaning would we rather have libc export a
&lt;br&gt;&amp;gt; &amp;gt; pthread_once() and that ideally libc would be using pthread_mutex_lock/unlock
&lt;br&gt;&amp;gt; &amp;gt; instead of _spinlock/unlock?
&lt;br&gt;&amp;gt; 
&lt;br&gt;&amp;gt; pthread_once() is already a stub in libc that gets overloaded with the
&lt;br&gt;&amp;gt; real thing when libthr is linked. &amp;nbsp;See libc/gen/_pthread_stubs.c.
&lt;br&gt;&amp;gt; Isn't that what you want or does it not serve your purpose?
&lt;/div&gt;&lt;br&gt;Hmm, the libc stub will never run the init routine. &amp;nbsp;I would like to do
&lt;br&gt;something like this:
&lt;br&gt;&lt;br&gt;Index: stdtime/localtime.c
&lt;br&gt;===================================================================
&lt;br&gt;--- stdtime/localtime.c	(revision 199529)
&lt;br&gt;+++ stdtime/localtime.c	(working copy)
&lt;br&gt;@@ -235,9 +235,8 @@
&lt;br&gt;&amp;nbsp;
&lt;br&gt;&amp;nbsp;static char		lcl_TZname[TZ_STRLEN_MAX + 1];
&lt;br&gt;&amp;nbsp;static int		lcl_is_set;
&lt;br&gt;-static int		gmt_is_set;
&lt;br&gt;+static pthread_once_t	gmt_once = PTHREAD_ONCE_INIT;
&lt;br&gt;&amp;nbsp;static pthread_rwlock_t	lcl_rwlock = PTHREAD_RWLOCK_INITIALIZER;
&lt;br&gt;-static pthread_mutex_t	gmt_mutex = PTHREAD_MUTEX_INITIALIZER;
&lt;br&gt;&amp;nbsp;
&lt;br&gt;&amp;nbsp;char *			tzname[2] = {
&lt;br&gt;&amp;nbsp;	wildabbr,
&lt;br&gt;@@ -1464,6 +1463,17 @@
&lt;br&gt;&amp;nbsp;	return tmp;
&lt;br&gt;&amp;nbsp;}
&lt;br&gt;&amp;nbsp;
&lt;br&gt;+static void
&lt;br&gt;+gmt_init(void)
&lt;br&gt;+{
&lt;br&gt;+
&lt;br&gt;+#ifdef ALL_STATE
&lt;br&gt;+	gmtptr = (struct state *) malloc(sizeof *gmtptr);
&lt;br&gt;+	if (gmtptr != NULL)
&lt;br&gt;+#endif /* defined ALL_STATE */
&lt;br&gt;+		gmtload(gmtptr);
&lt;br&gt;+}
&lt;br&gt;+
&lt;br&gt;&amp;nbsp;/*
&lt;br&gt;&amp;nbsp;** gmtsub is to gmtime as localsub is to localtime.
&lt;br&gt;&amp;nbsp;*/
&lt;br&gt;@@ -1476,16 +1486,7 @@
&lt;br&gt;&amp;nbsp;{
&lt;br&gt;&amp;nbsp;	register struct tm *	result;
&lt;br&gt;&amp;nbsp;
&lt;br&gt;-	_MUTEX_LOCK(&amp;gmt_mutex);
&lt;br&gt;-	if (!gmt_is_set) {
&lt;br&gt;-#ifdef ALL_STATE
&lt;br&gt;-		gmtptr = (struct state *) malloc(sizeof *gmtptr);
&lt;br&gt;-		if (gmtptr != NULL)
&lt;br&gt;-#endif /* defined ALL_STATE */
&lt;br&gt;-			gmtload(gmtptr);
&lt;br&gt;-		gmt_is_set = TRUE;
&lt;br&gt;-	}
&lt;br&gt;-	_MUTEX_UNLOCK(&amp;gmt_mutex);
&lt;br&gt;+	_pthread_once(&amp;gmt_once, gmt_init);
&lt;br&gt;&amp;nbsp;	result = timesub(timep, offset, gmtptr, tmp);
&lt;br&gt;&amp;nbsp;#ifdef TM_ZONE
&lt;br&gt;&amp;nbsp;	/*
&lt;br&gt;&lt;br&gt;&lt;br&gt;-- 
&lt;br&gt;John Baldwin
&lt;br&gt;_______________________________________________
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26430071&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads@...&lt;/a&gt; mailing list
&lt;br&gt;&lt;a href=&quot;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&lt;/a&gt;&lt;br&gt;To unsubscribe, send any mail to &amp;quot;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26430071&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads-unsubscribe@...&lt;/a&gt;&amp;quot;
&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Using-pthread_once%28%29-in-libc-tp26428253p26430071.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26429779</id>
	<title>Re: Using pthread_once() in libc</title>
	<published>2009-11-19T08:48:54Z</published>
	<updated>2009-11-19T08:48:54Z</updated>
	<author>
		<name>Daniel Eischen</name>
	</author>
	<content type="html">On Thu, 19 Nov 2009, John Baldwin wrote:
&lt;br&gt;&lt;div class='shrinkable-quote'&gt;&lt;br&gt;&amp;gt; I would like to provide a pthread_once()-like facility in libc that library
&lt;br&gt;&amp;gt; bits can use to initialize data safely rather than trying to home-roll their
&lt;br&gt;&amp;gt; own variants (see the recent commit to stdtime in libc). &amp;nbsp;Ideally what I
&lt;br&gt;&amp;gt; would like to do is have libc use the &amp;quot;real&amp;quot; pthread_once() when libthr is
&lt;br&gt;&amp;gt; linked in and fall back to a simple stub without libthr linked in. &amp;nbsp;I know we
&lt;br&gt;&amp;gt; already do something like this for _spinlock() and friends. &amp;nbsp;My question is
&lt;br&gt;&amp;gt; what is the most correct way to do this? &amp;nbsp;Should libc grow a new _once()
&lt;br&gt;&amp;gt; symbol ala _spinlock() that is a weak symbol to a stub version and
&lt;br&gt;&amp;gt; pthread_once() in thr_once.c would override that, or should there be a
&lt;br&gt;&amp;gt; _pthread_once() in libc that is a stub in place of the current stub_zero? &amp;nbsp;I
&lt;br&gt;&amp;gt; noticed a comment in thr_spinlock.c saying the spinlock stuff is kept for
&lt;br&gt;&amp;gt; backwards compat. &amp;nbsp;Does this mean that for the future we would like to expose
&lt;br&gt;&amp;gt; pthread symbols directly in libc? &amp;nbsp;Meaning would we rather have libc export a
&lt;br&gt;&amp;gt; pthread_once() and that ideally libc would be using pthread_mutex_lock/unlock
&lt;br&gt;&amp;gt; instead of _spinlock/unlock?
&lt;/div&gt;&lt;br&gt;pthread_once() is already a stub in libc that gets overloaded with the
&lt;br&gt;real thing when libthr is linked. &amp;nbsp;See libc/gen/_pthread_stubs.c.
&lt;br&gt;Isn't that what you want or does it not serve your purpose?
&lt;br&gt;&lt;br&gt;I think as soon as we get pthread lock types (at least mutex, cv's,
&lt;br&gt;and semaphores) implemented as structs instead of opaque pointers,
&lt;br&gt;then we can do away with the spinlocks. &amp;nbsp;Currently, the library
&lt;br&gt;knows that spinlocks are different and plays games to avoid
&lt;br&gt;allocation problems at startup. &amp;nbsp;At least that's my recollection.
&lt;br&gt;&lt;br&gt;-- 
&lt;br&gt;DE
&lt;br&gt;_______________________________________________
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26429779&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads@...&lt;/a&gt; mailing list
&lt;br&gt;&lt;a href=&quot;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&lt;/a&gt;&lt;br&gt;To unsubscribe, send any mail to &amp;quot;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26429779&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads-unsubscribe@...&lt;/a&gt;&amp;quot;
&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Using-pthread_once%28%29-in-libc-tp26428253p26429779.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26428253</id>
	<title>Using pthread_once() in libc</title>
	<published>2009-11-19T07:30:13Z</published>
	<updated>2009-11-19T07:30:13Z</updated>
	<author>
		<name>John Baldwin</name>
	</author>
	<content type="html">I would like to provide a pthread_once()-like facility in libc that library 
&lt;br&gt;bits can use to initialize data safely rather than trying to home-roll their 
&lt;br&gt;own variants (see the recent commit to stdtime in libc). &amp;nbsp;Ideally what I 
&lt;br&gt;would like to do is have libc use the &amp;quot;real&amp;quot; pthread_once() when libthr is 
&lt;br&gt;linked in and fall back to a simple stub without libthr linked in. &amp;nbsp;I know we 
&lt;br&gt;already do something like this for _spinlock() and friends. &amp;nbsp;My question is 
&lt;br&gt;what is the most correct way to do this? &amp;nbsp;Should libc grow a new _once() 
&lt;br&gt;symbol ala _spinlock() that is a weak symbol to a stub version and 
&lt;br&gt;pthread_once() in thr_once.c would override that, or should there be a 
&lt;br&gt;_pthread_once() in libc that is a stub in place of the current stub_zero? &amp;nbsp;I 
&lt;br&gt;noticed a comment in thr_spinlock.c saying the spinlock stuff is kept for 
&lt;br&gt;backwards compat. &amp;nbsp;Does this mean that for the future we would like to expose 
&lt;br&gt;pthread symbols directly in libc? &amp;nbsp;Meaning would we rather have libc export a 
&lt;br&gt;pthread_once() and that ideally libc would be using pthread_mutex_lock/unlock 
&lt;br&gt;instead of _spinlock/unlock?
&lt;br&gt;&lt;br&gt;-- 
&lt;br&gt;John Baldwin
&lt;br&gt;_______________________________________________
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26428253&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads@...&lt;/a&gt; mailing list
&lt;br&gt;&lt;a href=&quot;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&lt;/a&gt;&lt;br&gt;To unsubscribe, send any mail to &amp;quot;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26428253&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads-unsubscribe@...&lt;/a&gt;&amp;quot;
&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Using-pthread_once%28%29-in-libc-tp26428253p26428253.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26370187</id>
	<title>Current problem reports assigned to freebsd-threads@FreeBSD.org</title>
	<published>2009-11-16T03:07:02Z</published>
	<updated>2009-11-16T03:07:02Z</updated>
	<author>
		<name>FreeBSD bugmaster</name>
	</author>
	<content type="html">Note: to view an individual PR, use:
&lt;br&gt;&amp;nbsp; &lt;a href=&quot;http://www.freebsd.org/cgi/query-pr.cgi?pr=(number&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://www.freebsd.org/cgi/query-pr.cgi?pr=(number&lt;/a&gt;).
&lt;br&gt;&lt;br&gt;The following is a listing of current problems submitted by FreeBSD users.
&lt;br&gt;These represent problem reports covering all versions including
&lt;br&gt;experimental development code and obsolete releases.
&lt;br&gt;&lt;br&gt;&lt;br&gt;S Tracker &amp;nbsp; &amp;nbsp; &amp;nbsp;Resp. &amp;nbsp; &amp;nbsp; &amp;nbsp;Description
&lt;br&gt;--------------------------------------------------------------------------------
&lt;br&gt;o threa/136345 threads &amp;nbsp; &amp;nbsp;Recursive read rwlocks in thread A cause deadlock with
&lt;br&gt;o threa/135673 threads &amp;nbsp; &amp;nbsp;databases/mysql50-server - MySQL query lock-ups on 7.2
&lt;br&gt;p threa/135462 threads &amp;nbsp; &amp;nbsp;[PATCH] _thread_cleanupspecific() doesn't handle delet
&lt;br&gt;o threa/133734 threads &amp;nbsp; &amp;nbsp;32 bit libthr failing pthread_create()
&lt;br&gt;o threa/128922 threads &amp;nbsp; &amp;nbsp;threads hang with xorg running
&lt;br&gt;o threa/127225 threads &amp;nbsp; &amp;nbsp;bug in lib/libthr/thread/thr_init.c
&lt;br&gt;o threa/122923 threads &amp;nbsp; &amp;nbsp;'nice' does not prevent background process from steali
&lt;br&gt;o threa/121336 threads &amp;nbsp; &amp;nbsp;lang/neko threading ok on UP, broken on SMP (FreeBSD 7
&lt;br&gt;o threa/118715 threads &amp;nbsp; &amp;nbsp;kse problem
&lt;br&gt;o threa/116668 threads &amp;nbsp; &amp;nbsp;can no longer use jdk15 with libthr on -stable SMP
&lt;br&gt;o threa/116181 threads &amp;nbsp; &amp;nbsp;/dev/io-related io access permissions are not propagat
&lt;br&gt;o threa/115211 threads &amp;nbsp; &amp;nbsp;pthread_atfork misbehaves in initial thread
&lt;br&gt;o threa/110636 threads &amp;nbsp; &amp;nbsp;[request] gdb(1): using gdb with multi thread applicat
&lt;br&gt;o threa/110306 threads &amp;nbsp; &amp;nbsp;apache 2.0 segmentation violation when calling gethost
&lt;br&gt;o threa/103975 threads &amp;nbsp; &amp;nbsp;Implicit loading/unloading of libpthread.so may crash 
&lt;br&gt;o threa/101323 threads &amp;nbsp; &amp;nbsp;[patch] fork(2) in threaded programs broken.
&lt;br&gt;s threa/100815 threads &amp;nbsp; &amp;nbsp;FBSD 5.5 broke nanosleep in libc_r
&lt;br&gt;s threa/94467 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;send(), sendto() and sendmsg() are not correct in libc
&lt;br&gt;s threa/84483 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;problems with devel/nspr and -lc_r on 4.x
&lt;br&gt;o threa/83914 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;[libc] popen() doesn't work in static threaded program
&lt;br&gt;o threa/80992 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;abort() sometimes not caught by gdb depending on threa
&lt;br&gt;o threa/80435 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;panic on high loads
&lt;br&gt;o threa/79887 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;[patch] freopen() isn't thread-safe
&lt;br&gt;o threa/79683 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;svctcp_create() fails if multiple threads call at the 
&lt;br&gt;s threa/76694 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;fork cause hang in dup()/close() function in child (-l
&lt;br&gt;s threa/76690 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;fork hang in child for -lc_r
&lt;br&gt;o threa/75374 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;pthread_kill() ignores SA_SIGINFO flag
&lt;br&gt;o threa/75273 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;FBSD 5.3 &amp;nbsp;libpthread (KSE) bug
&lt;br&gt;o threa/72953 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST
&lt;br&gt;o threa/70975 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;[sysvipc] unexpected and unreliable behaviour when usi
&lt;br&gt;s threa/69020 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;pthreads library leaks _gc_mutex
&lt;br&gt;s threa/49087 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;Signals lost in programs linked with libc_r
&lt;br&gt;s threa/48856 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;Setting SIGCHLD to SIG_IGN still leaves zombies under 
&lt;br&gt;s threa/40671 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;pthread_cancel doesn't remove thread from condition qu
&lt;br&gt;s threa/39922 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;[threads] [patch] Threaded applications executed with 
&lt;br&gt;s threa/37676 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra
&lt;br&gt;s threa/34536 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;accept() blocks other threads
&lt;br&gt;s threa/32295 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;[libc_r] [patch] pthread(3) dont dequeue signals
&lt;br&gt;s threa/30464 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;pthread mutex attributes -- pshared
&lt;br&gt;s threa/24632 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;libc_r delicate deviation from libc in handling SIGCHL
&lt;br&gt;s threa/24472 &amp;nbsp;threads &amp;nbsp; &amp;nbsp;libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o
&lt;br&gt;&lt;br&gt;41 problems total.
&lt;br&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26370187&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads@...&lt;/a&gt; mailing list
&lt;br&gt;&lt;a href=&quot;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&lt;/a&gt;&lt;br&gt;To unsubscribe, send any mail to &amp;quot;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26370187&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads-unsubscribe@...&lt;/a&gt;&amp;quot;
&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/Current-problem-reports-assigned-to-freebsd-threads%40FreeBSD.org-tp26370187p26370187.html" />
</entry>

<entry>
	<id>tag:old.nabble.com,2006:post-26371039</id>
	<title>how to build libthr except other components of 'world'</title>
	<published>2009-11-16T02:48:31Z</published>
	<updated>2009-11-16T02:48:31Z</updated>
	<author>
		<name>Jiandong Lu-2</name>
	</author>
	<content type="html">Hi,everyone,
&lt;br&gt;    I checkout FreeBSD‘s source codes to my /usr/src
&lt;br&gt;    I use command 
&lt;br&gt;    make buildworld 
&lt;br&gt;    int directory /usr/src to build a world.I want to do some debug to lib /usr/src/lib/libthr.If I modified some files in /usr/src/lib/libthr/thread, how could I build libthr except other components of world?
&lt;br&gt;   btw,I execute command 
&lt;br&gt;   make
&lt;br&gt;   in /usr/src/lib/libthr get this :
&lt;br&gt;cc -O2 -fno-strict-aliasing -pipe  -DPTHREAD_KERNEL -I/usr/src/lib/libthr/../libc/include -I/usr/src/lib/libthr/thread  -I/usr/src/lib/libthr/../../include -I/usr/src/lib/libthr/arch/i386/include -I/usr/src/lib/libthr/sys -I/usr/src/lib/libthr/../../libexec/rtld-elf -I/usr/src/lib/libthr/../../libexec/rtld-elf/i386 -I/usr/src/lib/libthr/../libthread_db -Winline -D_PTHREADS_INVARIANTS -DSYSCALL_COMPAT -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libthr/arch/i386/i386/pthread_md.c
&lt;br&gt;In file included from /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:33:
&lt;br&gt;/usr/src/lib/libthr/../../include/string.h:86: warning: no previous prototype for 'strdup'
&lt;br&gt;/usr/src/lib/libthr/../../include/string.h: In function 'strdup':
&lt;br&gt;/usr/src/lib/libthr/../../include/string.h:86: error: expected declaration specifiers before '__malloc_like'
&lt;br&gt;/usr/src/lib/libthr/../../include/string.h:96: warning: '__pure__' attribute ignored
&lt;br&gt;/usr/src/lib/libthr/../../include/string.h:101: warning: '__pure__' attribute ignored
&lt;br&gt;/usr/src/lib/libthr/../../include/string.h:104: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__malloc_like'
&lt;br&gt;/usr/src/lib/libthr/../../include/string.h:105: warning: '__pure__' attribute ignored
&lt;br&gt;/usr/src/lib/libthr/../../include/string.h:108: warning: '__pure__' attribute ignored
&lt;br&gt;/usr/src/lib/libthr/../../include/string.h:110: warning: '__pure__' attribute ignored
&lt;br&gt;/usr/src/lib/libthr/../../include/string.h:111: warning: '__pure__' attribute ignored
&lt;br&gt;/usr/src/lib/libthr/../../include/string.h:118: warning: '__pure__' attribute ignored
&lt;br&gt;/usr/src/lib/libthr/../../include/string.h:119: warning: '__pure__' attribute ignored
&lt;br&gt;In file included from /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:34:
&lt;br&gt;/usr/src/lib/libthr/../../libexec/rtld-elf/rtld_tls.h:60: error: storage class specified for parameter '_rtld_allocate_tls'
&lt;br&gt;/usr/src/lib/libthr/../../libexec/rtld-elf/rtld_tls.h:67: error: storage class specified for parameter '_rtld_free_tls'
&lt;br&gt;In file included from /usr/src/lib/libthr/arch/i386/include/pthread_md.h:36,
&lt;br&gt;                 from /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:36:
&lt;br&gt;/usr/src/lib/libthr/../../include/stddef.h:45: error: storage class specified for parameter 'ptrdiff_t'
&lt;br&gt;/usr/src/lib/libthr/../../include/stddef.h:49: error: storage class specified for parameter 'rune_t'
&lt;br&gt;/usr/src/lib/libthr/../../include/stddef.h:61: error: storage class specified for parameter 'wchar_t'
&lt;br&gt;In file included from /usr/src/lib/libthr/arch/i386/i386/pthread_md.c:36:
&lt;br&gt;/usr/src/lib/libthr/arch/i386/include/pthread_md.h:52: warning: empty declaration
&lt;br&gt;/usr/src/lib/libthr/arch/i386/include/pthread_md.h:88: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
&lt;br&gt;/usr/src/lib/libthr/arch/i386/include/pthread_md.h:95: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
&lt;br&gt;/usr/src/lib/libthr/arch/i386/include/pthread_md.h:102: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
&lt;br&gt;/usr/src/lib/libthr/arch/i386/i386/pthread_md.c:40: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
&lt;br&gt;/usr/src/lib/libthr/arch/i386/i386/pthread_md.c:54: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
&lt;br&gt;/usr/src/lib/libthr/arch/i386/i386/pthread_md.c:57: error: old-style parameter declarations in prototyped function definition
&lt;br&gt;/usr/src/lib/libthr/../../include/string.h:86: error: parameter name omitted
&lt;br&gt;/usr/src/lib/libthr/arch/i386/i386/pthread_md.c:57: error: expected '{' at end of input
&lt;br&gt;*** Error code 1
&lt;br&gt;&lt;br&gt;Stop in /usr/src/lib/libthr.
&lt;br&gt;----------------------------------
&lt;br&gt;thanks.
&lt;br&gt;&lt;br&gt;  
&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; ___________________________________________________________ 
&lt;br&gt;&amp;nbsp; 好玩贺卡等你发，邮箱贺卡全新上线！ 
&lt;br&gt;&lt;a href=&quot;http://card.mail.cn.yahoo.com/&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://card.mail.cn.yahoo.com/&lt;/a&gt;&lt;br&gt;_______________________________________________
&lt;br&gt;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26371039&amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads@...&lt;/a&gt; mailing list
&lt;br&gt;&lt;a href=&quot;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;http://lists.freebsd.org/mailman/listinfo/freebsd-threads&lt;/a&gt;&lt;br&gt;To unsubscribe, send any mail to &amp;quot;&lt;a href=&quot;http://old.nabble.com/user/SendEmail.jtp?type=post&amp;post=26371039&amp;i=1&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot;&gt;freebsd-threads-unsubscribe@...&lt;/a&gt;&amp;quot;
&lt;br&gt;</content>
	<link rel="alternate" type="text/html" href="http://old.nabble.com/how-to-build-libthr-except-other-components-of-%27world%27-tp26371039p26371039.html" />
</entry>

</feed>
