On Thu, Jun 04, 2020 at 06:26:07PM +, Martin Husemann wrote:
> On Wed, Jun 03, 2020 at 10:10:24PM +, Andrew Doran wrote:
> > Module Name:src
> > Committed By: ad
> > Date: Wed Jun 3 22:10:24 UTC 2020
> >
> > Modified Files:
> > src/lib/libpthread: pthread.
On Thu, Jun 04, 2020 at 09:28:09PM +, Andrew Doran wrote:
> On Thu, Jun 04, 2020 at 06:26:07PM +, Martin Husemann wrote:
>
> > On Wed, Jun 03, 2020 at 10:10:24PM +, Andrew Doran wrote:
> > > Module Name: src
> > > Committed By: ad
> > > Date: Wed Jun 3 22:10:24 U
Hi,
On Thu, Jun 04, 2020 at 06:26:07PM +, Martin Husemann wrote:
> On Wed, Jun 03, 2020 at 10:10:24PM +, Andrew Doran wrote:
> > Module Name:src
> > Committed By: ad
> > Date: Wed Jun 3 22:10:24 UTC 2020
> >
> > Modified Files:
> > src/lib/libpthread: pth
On Wed, Jun 03, 2020 at 10:10:24PM +, Andrew Doran wrote:
> Module Name: src
> Committed By: ad
> Date: Wed Jun 3 22:10:24 UTC 2020
>
> Modified Files:
> src/lib/libpthread: pthread.c pthread_cond.c pthread_mutex.c
>
> Log Message:
> Deal with a couple of problems with threads
Hi,
Kamil Rytarowski writes:
> On 13.02.2020 20:03, Ryo ONODERA wrote:
>> Hi,
>>
>> Kamil Rytarowski writes:
>>
>>> On 12.02.2020 15:01, Ryo ONODERA wrote:
Hi,
Kamil Rytarowski writes:
> Hello,
>
> I will have a look at them.
Thank you.
Real fix
On 13.02.2020 20:03, Ryo ONODERA wrote:
> Hi,
>
> Kamil Rytarowski writes:
>
>> On 12.02.2020 15:01, Ryo ONODERA wrote:
>>> Hi,
>>>
>>> Kamil Rytarowski writes:
>>>
Hello,
I will have a look at them.
>>>
>>> Thank you.
>>> Real fix is welcome.
>>>
>>> And multimedia/handbrake has
Hi,
Kamil Rytarowski writes:
> On 12.02.2020 15:01, Ryo ONODERA wrote:
>> Hi,
>>
>> Kamil Rytarowski writes:
>>
>>> Hello,
>>>
>>> I will have a look at them.
>>
>> Thank you.
>> Real fix is welcome.
>>
>> And multimedia/handbrake has workaround already.
>> I have workaround patches for lan
On 12.02.2020 15:01, Ryo ONODERA wrote:
> Hi,
>
> Kamil Rytarowski writes:
>
>> Hello,
>>
>> I will have a look at them.
>
> Thank you.
> Real fix is welcome.
>
> And multimedia/handbrake has workaround already.
> I have workaround patches for lang/mono6 (like your nspr patch).
> I will commit
Hi,
Kamil Rytarowski writes:
> Hello,
>
> I will have a look at them.
Thank you.
Real fix is welcome.
And multimedia/handbrake has workaround already.
I have workaround patches for lang/mono6 (like your nspr patch).
I will commit them after some tests.
> On 12.02.2020 14:02, Ryo ONODERA wrote
Hello,
I will have a look at them.
On 12.02.2020 14:02, Ryo ONODERA wrote:
> Hi,
>
> Kamil Rytarowski writes:
>
>> Please apple workaround (same like in NSPR) for now if fixing is difficult.
>>
>> Such bugs can have security implications.
>
> Adding workarounds will not improve security probl
Hi,
Kamil Rytarowski writes:
> Please apple workaround (same like in NSPR) for now if fixing is difficult.
>
> Such bugs can have security implications.
Adding workarounds will not improve security problems.
And I feel that such workarounds will not be accepted by upstream.
I will add workaroun
Please apple workaround (same like in NSPR) for now if fixing is difficult.
Such bugs can have security implications.
On 12.02.2020 09:49, Ryo ONODERA wrote:
> Hi,
>
> I have two problematic pkgsrc packages at least.
> Of course these programs have misuses and/or bugs, however I feel that
> deal
Hi,
I have two problematic pkgsrc packages at least.
Of course these programs have misuses and/or bugs, however I feel that
dealing pt_magic in pthread_equal() is too hasty for pkgsrc.
multimedia/handbrake (internal libbluray):
The invalid thread pointer is not NULL.
pthread_equal t1: 0xf
On 03.02.2020 17:10, Ryo ONODERA wrote:
> Hi,
>
> Kamil Rytarowski writes:
>
>> Please check this workaround:
>>
>> http://netbsd.org/~kamil/patch-00224-firefox-pthread_equal.txt
>>
>> It has to be applied on firefox's package.
>
> Thank you very much.
>
> This should be applied to pkgsrc/deve
Hi,
Kamil Rytarowski writes:
> On 03.02.2020 17:10, Ryo ONODERA wrote:
>> Hi,
>>
>> Kamil Rytarowski writes:
>>
>>> Please check this workaround:
>>>
>>> http://netbsd.org/~kamil/patch-00224-firefox-pthread_equal.txt
>>>
>>> It has to be applied on firefox's package.
>>
>> Thank you very muc
Hi,
Kamil Rytarowski writes:
> Please check this workaround:
>
> http://netbsd.org/~kamil/patch-00224-firefox-pthread_equal.txt
>
> It has to be applied on firefox's package.
Thank you very much.
This should be applied to pkgsrc/devel/nspr with slight change.
(devel/nspr's C files cannot accep
Please check this workaround:
http://netbsd.org/~kamil/patch-00224-firefox-pthread_equal.txt
It has to be applied on firefox's package.
The problem has to be reported upstream as a real bug.
On 03.02.2020 16:01, Ryo ONODERA wrote:
> Hi,
>
> Ryo ONODERA writes:
>
>> Hi,
>>
>> I had tested wit
Hi,
Ryo ONODERA writes:
> Hi,
>
> I had tested with PTHREAD_DIAGASSERT however it did not produce any output.
>
> I am building current and pkgsrc packages from scratch now.
>
> I will reply my situation after this rebuild.
>
> Thank you.
With latest toolchain, kernel and userland,
my firefox g
Hi,
I had tested with PTHREAD_DIAGASSERT however it did not produce any output.
I am building current and pkgsrc packages from scratch now.
I will reply my situation after this rebuild.
Thank you.
On February 3, 2020 7:23:33 AM GMT+09:00, Kamil Rytarowski wrote:
>Hello,
>
>I've checked with N
Hello,
I've checked with NetBSD-current from today (2020-02-02) and
pkgsrc-current (2020-02-02) and package firefox-72.0.2.
I'm not reproducing any crash due to pthread_equal(3) misuse. Everything
I tested, worked for me.
Please try PTHREAD_DIAGASSERT=ae and debug the culprit crash with a
core(5
Good idea. It could be checked quicker... however I presume that
t1->pt_magic + t1->pt_magic already crash on invalid t1/t2 pointers as
the argument with condition is evaluated.
Ryo, you might check:
$ export PTHREAD_DIAGASSERT=ae
$ firefox
It should create a coredump for investigation.
Accordin
Hmm. Was there not originally an environment variable to control this
behaviour, since many applications are buggy?
Andrew
On Sun, Feb 02, 2020 at 01:01:49AM +0900, Ryo ONODERA wrote:
> Hi,
>
> pthread__error()s in pthread_equal() cause segfault
> during start of pkgsrc/www/firefox-72.0.2.
>
>
Kamil Rytarowski writes:
> On 01.02.2020 17:01, Ryo ONODERA wrote:
>> Hi,
>>
>> pthread__error()s in pthread_equal() cause segfault
>> during start of pkgsrc/www/firefox-72.0.2.
>>
>> Without pthread__error()s, www/firefox works fine
>> like as follows.
>> However I have no idea why I get segfa
On 01.02.2020 17:01, Ryo ONODERA wrote:
> Hi,
>
> pthread__error()s in pthread_equal() cause segfault
> during start of pkgsrc/www/firefox-72.0.2.
>
> Without pthread__error()s, www/firefox works fine
> like as follows.
> However I have no idea why I get segfaults.
>
> Could you take a look at t
Hi,
pthread__error()s in pthread_equal() cause segfault
during start of pkgsrc/www/firefox-72.0.2.
Without pthread__error()s, www/firefox works fine
like as follows.
However I have no idea why I get segfaults.
Could you take a look at this problem?
Index: lib/libpthread/pthread.c
==
Actually it happened that modifiying pthread_atfork() to stop
malloc()ing is enough to address the problem.
I have landed the changes and removed '#if 0' kludge.
Thanks!
On 01.02.2020 13:59, Kamil Rytarowski wrote:
> On 31.01.2020 22:10, Andrew Doran wrote:
>> On Fri, Jan 31, 2020 at 06:55:00PM
On 31.01.2020 22:10, Andrew Doran wrote:
> On Fri, Jan 31, 2020 at 06:55:00PM -, Christos Zoulas wrote:
>
>> In article <724af477-010b-9ddf-6ece-e23d7cf59...@gmx.com>,
>> Kamil Rytarowski wrote:
>>> -=-=-=-=-=-
>>> -=-=-=-=-=-
>>>
>>> On 31.01.2020 03:38, Christos Zoulas wrote:
And it i
On Fri, Jan 31, 2020 at 06:55:00PM -, Christos Zoulas wrote:
> In article <724af477-010b-9ddf-6ece-e23d7cf59...@gmx.com>,
> Kamil Rytarowski wrote:
> >-=-=-=-=-=-
> >-=-=-=-=-=-
> >
> >On 31.01.2020 03:38, Christos Zoulas wrote:
> >> And it is fixed now.
> >>
> >> christos
> >>
> >
> >OK.
On 31.01.2020 19:55, Christos Zoulas wrote:
> In article <724af477-010b-9ddf-6ece-e23d7cf59...@gmx.com>,
> Kamil Rytarowski wrote:
>> -=-=-=-=-=-
>> -=-=-=-=-=-
>>
>> On 31.01.2020 03:38, Christos Zoulas wrote:
>>> And it is fixed now.
>>>
>>> christos
>>>
>>
>> OK. I am going to submit a bug rep
In article <724af477-010b-9ddf-6ece-e23d7cf59...@gmx.com>,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>On 31.01.2020 03:38, Christos Zoulas wrote:
>> And it is fixed now.
>>
>> christos
>>
>
>OK. I am going to submit a bug report upstream and get some feedback
>what is the way forward
On 31.01.2020 03:38, Christos Zoulas wrote:
> And it is fixed now.
>
> christos
>
OK. I am going to submit a bug report upstream and get some feedback
what is the way forward here, delaying initialization.
signature.asc
Description: OpenPGP digital signature
And it is fixed now.
christos
signature.asc
Description: Message signed with OpenPGP
At this point I'd say it is simpler to just initialize the mutexattr_t fields
in a new
libc stub for the attribute init.
christos
> On Jan 30, 2020, at 8:05 PM, Kamil Rytarowski wrote:
>
> Signed PGP part
> On 05.03.2019 23:49, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:
On 05.03.2019 23:49, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Tue Mar 5 22:49:38 UTC 2019
>
> Modified Files:
> src/lib/libpthread: pthread_mutex.c
>
> Log Message:
> Jemalloc initializes mutexes before we become threaded and expects to use
> them
On Tue, May 07, 2019 at 06:14:09PM +, m...@netbsd.org wrote:
> Pre-emptively making a thread where people can call this an ugly hack
It is, please put a note into doc/HACKS at least.
Joerg
Pre-emptively making a thread where people can call this an ugly hack
On Tue, May 07, 2019 at 06:12:54PM +, Maya Rashish wrote:
> Module Name: src
> Committed By: maya
> Date: Tue May 7 18:12:53 UTC 2019
>
> Modified Files:
> src/lib/libpthread: Makefile
>
> Log Message:
> Re
netbsd-8 needs a web browser too
On Tue, Aug 01, 2017 at 12:31:45PM +, Martin Husemann wrote:
> Module Name: src
> Committed By: martin
> Date: Tue Aug 1 12:31:45 UTC 2017
>
> Modified Files:
> src/lib/libpthread: pthread_attr.c
>
> Log Message:
> pthread__attr_init_private:
> Date: Tue, 28 Mar 2017 20:10:24 +0200
> From: Joerg Sonnenberger
>
> On Tue, Mar 28, 2017 at 05:42:53PM +, Maya Rashish wrote:
> > Remove outdated CAVEATS.
> >
> > Not sure everything is standards compliant, but I've been told non-default
> > values are supported and pshared exists.
>
> p
On Tue, Mar 28, 2017 at 05:42:53PM +, Maya Rashish wrote:
> Module Name: src
> Committed By: maya
> Date: Tue Mar 28 17:42:52 UTC 2017
>
> Modified Files:
> src/lib/libpthread: pthread_condattr.3
>
> Log Message:
> Remove outdated CAVEATS.
>
> Not sure everything is standards
On Mon, Aug 24, 2015 at 03:03:28PM +, Antti Kantee wrote:
> On 24/08/15 14:36, Joerg Sonnenberger wrote:
> >On Mon, Aug 24, 2015 at 02:20:55PM +, Antti Kantee wrote:
> >>On 24/08/15 13:26, Joerg Sonnenberger wrote:
> >>>On Mon, Aug 24, 2015 at 12:45:15PM +, Antti Kantee wrote:
> I s
On 24/08/15 14:36, Joerg Sonnenberger wrote:
On Mon, Aug 24, 2015 at 02:20:55PM +, Antti Kantee wrote:
On 24/08/15 13:26, Joerg Sonnenberger wrote:
On Mon, Aug 24, 2015 at 12:45:15PM +, Antti Kantee wrote:
I started work on this again by doing a web search for the error, and found
this
On Mon, Aug 24, 2015 at 02:20:55PM +, Antti Kantee wrote:
> On 24/08/15 13:26, Joerg Sonnenberger wrote:
> >On Mon, Aug 24, 2015 at 12:45:15PM +, Antti Kantee wrote:
> >>I started work on this again by doing a web search for the error, and found
> >>this:
> >>http://bugs.musicpd.org/view.ph
On 24/08/15 13:26, Joerg Sonnenberger wrote:
On Mon, Aug 24, 2015 at 12:45:15PM +, Antti Kantee wrote:
I started work on this again by doing a web search for the error, and found
this:
http://bugs.musicpd.org/view.php?id=4110
There you argue that using constexpr for PTHREAD_MUTEX_INITIALIZE
On Mon, Aug 24, 2015 at 12:45:15PM +, Antti Kantee wrote:
> I started work on this again by doing a web search for the error, and found
> this:
> http://bugs.musicpd.org/view.php?id=4110
>
> There you argue that using constexpr for PTHREAD_MUTEX_INITIALIZER is
> broken. So if we assume that y
Returning to this pickle.
On 26/06/15 18:24, Joerg Sonnenberger wrote:
On Fri, Jun 26, 2015 at 12:49:09PM +, Antti Kantee wrote:
This is the simplest program to repeat the problem with g++ 5.1 and NetBSD's
pthread_types.h:
#include
class foo {
pthread_mutex_t m;
public:
co
On Fri, Jun 26, 2015 at 12:49:09PM +, Antti Kantee wrote:
> This is the simplest program to repeat the problem with g++ 5.1 and NetBSD's
> pthread_types.h:
>
> #include
> class foo {
> pthread_mutex_t m;
> public:
> constexpr foo() : m(PTHREAD_MUTEX_INITIALIZER) {}
> };
>
> (plus
On Fri, Jun 26, 2015 at 12:07:36PM +, Antti Kantee wrote:
> On 26/06/15 11:53, Joerg Sonnenberger wrote:
> >That said, have
> >you verified why it doesn't happen with libstdc++ itself? I would
> >somewhat suspect that the threatment of the header as system header
> >hides the problem for libstd
This is the simplest program to repeat the problem with g++ 5.1 and
NetBSD's pthread_types.h:
#include
class foo {
pthread_mutex_t m;
public:
constexpr foo() : m(PTHREAD_MUTEX_INITIALIZER) {}
};
(plus or minus typos since I typed it by hand from the virtual machine
console)
On 26/06/15 11:53, Joerg Sonnenberger wrote:
That said, have
you verified why it doesn't happen with libstdc++ itself? I would
somewhat suspect that the threatment of the header as system header
hides the problem for libstdc++, I can't imagine that it can correctly
implement the constexpr constru
On Fri, Jun 26, 2015 at 10:14:41AM +, Antti Kantee wrote:
> As long as NetBSD's goals include "interoperates well with other systems"
> and "conforms to open systems standards as much as is practical", the
> workaround is mandated. It fixes source level interoperation with a
> contemporary rel
On 26/06/15 06:02, Martin Husemann wrote:
On Fri, Jun 26, 2015 at 01:38:45AM +, Antti Kantee wrote:
On Fri, Jun 26, 2015 at 01:33:09AM +, Antti Kantee wrote:
Module Name:src
Committed By: pooka
Date: Fri Jun 26 01:33:09 UTC 2015
Modified Files:
src/lib/libpthrea
On 26/06/15 07:04, Nick Hudson wrote:
On 06/26/15 02:33, Antti Kantee wrote:
+# ifdef __CPU_SIMPLE_LOCK_PAD
+# define __pthread_spin_t unsigned char
+# else
+# define __pthread_spin_t unsigned int
+# endif
Are you sure this "works" for hppa which has funky __cpu_simple_lock_t?
Slightly rel
On 26/06/15 09:14, Joerg Sonnenberger wrote:
On Fri, Jun 26, 2015 at 01:33:09AM +, Antti Kantee wrote:
Module Name:src
Committed By: pooka
Date: Fri Jun 26 01:33:09 UTC 2015
Modified Files:
src/lib/libpthread: pthread_types.h
Log Message:
C++ (namely libc++) expects
On 26/06/15 07:04, Nick Hudson wrote:
On 06/26/15 02:33, Antti Kantee wrote:
+# ifdef __CPU_SIMPLE_LOCK_PAD
+# define __pthread_spin_t unsigned char
+# else
+# define __pthread_spin_t unsigned int
+# endif
Are you sure this "works" for hppa which has funky __cpu_simple_lock_t?
You're right
On Fri, Jun 26, 2015 at 01:33:09AM +, Antti Kantee wrote:
> Module Name: src
> Committed By: pooka
> Date: Fri Jun 26 01:33:09 UTC 2015
>
> Modified Files:
> src/lib/libpthread: pthread_types.h
>
> Log Message:
> C++ (namely libc++) expects to be using PTHREAD_FOO_INITIALIZER a
On 06/26/15 02:33, Antti Kantee wrote:
+# ifdef __CPU_SIMPLE_LOCK_PAD
+# define __pthread_spin_t unsigned char
+# else
+# define __pthread_spin_t unsigned int
+# endif
Are you sure this "works" for hppa which has funky __cpu_simple_lock_t?
Nick
On Fri, Jun 26, 2015 at 01:38:45AM +, Antti Kantee wrote:
> On Fri, Jun 26, 2015 at 01:33:09AM +, Antti Kantee wrote:
> > Module Name:src
> > Committed By: pooka
> > Date: Fri Jun 26 01:33:09 UTC 2015
> >
> > Modified Files:
> > src/lib/libpthread: pthread_t
On Fri, Jun 26, 2015 at 01:33:09AM +, Antti Kantee wrote:
> Module Name: src
> Committed By: pooka
> Date: Fri Jun 26 01:33:09 UTC 2015
>
> Modified Files:
> src/lib/libpthread: pthread_types.h
>
> Log Message:
> C++ (namely libc++) expects to be using PTHREAD_FOO_INITIALIZER a
In article <20141217014908.359b...@cvs.netbsd.org>,
Antti Kantee wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: pooka
>Date: Wed Dec 17 01:49:08 UTC 2014
>
>Modified Files:
> src/lib/libpthread: pthread_makelwp_netbsd.c
>
>Log Message:
>include correct header for "last mi
On Apr 2, 1:46am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/lib/libpthread
| > I think it is too late now.
|
| Hmm. If core and releng think so, I have no further comment.
| (but I'm afraid we need 6.1_RC4 anyway since RC3 doesn't include pthre
> | Can't we simply revert ticket #722 (pthread_condattr_setclock(3) addition)?
> | Is that function really necessary for 6.1?
>
> I think it is too late now.
Hmm. If core and releng think so, I have no further comment.
(but I'm afraid we need 6.1_RC4 anyway since RC3 doesn't include pthread fixe
On Apr 2, 1:22am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/lib/libpthread
| > It depends on where we build 3rd party binaries. If we build on
| > the earliest branch there is no problem. But if we build in the
| > latest one there is. We should
> | > >| Furthermore, was it safe to add a new pthread_condattr_setclock(3)
> function
> | > >| without libpthread minor bump? I'm afraid pkgsrc ruby193 (and other)
> | > >| binaries built on 6.1 silently fails on 6.0.1.
> | > >
> | > >It was a mistake, we should have bumped.
> | >
> | > Note, t
On Apr 1, 11:43pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/lib/libpthread
| > >| Furthermore, was it safe to add a new pthread_condattr_setclock(3)
function
| > >| without libpthread minor bump? I'm afraid pkgsrc ruby193 (and other)
| &g
> >| Furthermore, was it safe to add a new pthread_condattr_setclock(3) function
> >| without libpthread minor bump? I'm afraid pkgsrc ruby193 (and other)
> >| binaries built on 6.1 silently fails on 6.0.1.
> >
> >It was a mistake, we should have bumped.
>
> Note, that bumping would have just cha
In article <20130401132606.8cc2997...@rebar.astron.com>,
Christos Zoulas wrote:
>
>| Furthermore, was it safe to add a new pthread_condattr_setclock(3) function
>| without libpthread minor bump? I'm afraid pkgsrc ruby193 (and other)
>| binaries built on 6.1 silently fails on 6.0.1.
>
>It was a mi
On Apr 1, 9:18pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/lib/libpthread
| Will this workaround fix for PR lib/47703 be pulled to 6.1 release?
Yes,
| Does releng have any plan for all libpthread issue (including dlopen one)?
This is an open question to
Will this workaround fix for PR lib/47703 be pulled to 6.1 release?
Does releng have any plan for all libpthread issue (including dlopen one)?
IMO ticket #722 (pthread_condattr_setclock(3) addition) should be
reverted before 6.1 if it requires syscall bump for the "real" fix.
Furthermore, was it
On Apr 1, 3:02am, y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
-- Subject: Re: CVS commit: src/lib/libpthread
| > Yes, I already added it to lwp_park to avoid the hack but not using
| > the syscall yet until we decide what we need to pass to lwp_park
| > to avoid priority inversio
> In article <20130329032804.23b1514a...@mail.netbsd.org>,
> YAMAMOTO Takashi wrote:
>>
>>"mono" escaping its scope?
>
> Yes, I already added it to lwp_park to avoid the hack but not using
> the syscall yet until we decide what we need to pass to lwp_park
> to avoid priority inversion and fix the
In article <20130329032804.23b1514a...@mail.netbsd.org>,
YAMAMOTO Takashi wrote:
>
>"mono" escaping its scope?
Yes, I already added it to lwp_park to avoid the hack but not using
the syscall yet until we decide what we need to pass to lwp_park
to avoid priority inversion and fix the races in pthr
> Module Name: src
> Committed By: christos
> Date: Thu Mar 28 18:07:12 UTC 2013
>
> Modified Files:
> src/lib/libpthread: pthread_cond.c
>
> Log Message:
> PR/47703: Yasushi Oshima: pthread_cond_timedwait() does not wait
> after call pthread_condattr_setclock(CLOCK_MONOTONIC)
>
>
On Nov 22, 9:14am, mar...@duskware.de (Martin Husemann) wrote:
-- Subject: Re: CVS commit: src/lib/libpthread
| On Wed, Nov 21, 2012 at 07:35:29PM -0500, Christos Zoulas wrote:
| > Ok, that's simple to change. But where is the documentation for how this
| > is supposed to work, so
On Wed, Nov 21, 2012 at 07:35:29PM -0500, Christos Zoulas wrote:
> Ok, that's simple to change. But where is the documentation for how this
> is supposed to work, so I can put a cross-reference to it.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_key_delete.html
It is the re
On Nov 21, 10:51pm, y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
-- Subject: Re: CVS commit: src/lib/libpthread
| > Replace the simple implementation of pthread_key_{create,destroy}
| > and pthread_{g,s}etspecific functions, to one that invalidates
| > values of keys in other thr
hi,
> Module Name: src
> Committed By: christos
> Date: Wed Nov 21 19:19:25 UTC 2012
>
> Modified Files:
> src/lib/libpthread: pthread_int.h pthread_specific.c pthread_tsd.c
>
> Log Message:
> Replace the simple implementation of pthread_key_{create,destroy}
> and pthread_{g,s}ets
On Sep 12, 2012, at 9:45 AM, David Laight wrote:
> On Wed, Sep 12, 2012 at 02:55:48PM +, Matt Thomas wrote:
>> Module Name: src
>> Committed By:matt
>> Date:Wed Sep 12 14:55:48 UTC 2012
>>
>> Modified Files:
>> src/lib/libpthread: pthread_specific.c
>>
>> Log Me
On Wed, Sep 12, 2012 at 02:55:48PM +, Matt Thomas wrote:
> Module Name: src
> Committed By: matt
> Date: Wed Sep 12 14:55:48 UTC 2012
>
> Modified Files:
> src/lib/libpthread: pthread_specific.c
>
> Log Message:
> Only copy the ucontext_t in pthread_setcontext if _UC_TLSBASE is
On Sat, Mar 10, 2012 at 06:01:10PM +, Joerg Sonnenberger wrote:
> cvs rdiff -u -r1.23 -r1.24 src/lib/libpthread/sem.c
This part wasn't originally intended, so I changed the commit message to
"Fix error handling". It doesn't hurt either.
Joerg
On Aug 6, 12:59pm, m.droch...@fz-juelich.de (Matthias Drochner) wrote:
-- Subject: Re: CVS commit: src/lib/libpthread
| chris...@zoulas.com said:
| > They are different and pthread_attr_get_np() is not weak...
|
| But pthread_attr_get_np() is now used internally.
| The rule is that functi
chris...@zoulas.com said:
> They are different and pthread_attr_get_np() is not weak...
But pthread_attr_get_np() is now used internally.
The rule is that functions which are used internally
and not part of standard C need to be protected.
best regards
Matthias
---
On Aug 6, 12:26pm, m.droch...@fz-juelich.de (Matthias Drochner) wrote:
-- Subject: Re: CVS commit: src/lib/libpthread
|
| > Module Name:src
| > Committed By: christos
| > Date: Fri Aug 6 05:25:02 UTC 2010
| >
| > Modified Files:
| > src/lib/lib
> Module Name:src
> Committed By: christos
> Date: Fri Aug 6 05:25:02 UTC 2010
>
> Modified Files:
> src/lib/libpthread: pthread.h pthread_attr.c
>
> Log Message: Add pthread_getattr_np()
I think this needs a weak_alias for pthread_attr_get_np().
best regards
Matthias
On Tue, May 18, 2010 at 11:04:12AM +0300, Jukka Ruohonen wrote:
> In my opinion we could have more introductory sections that connect the
> pages in a more logical manner.[1] Just listing the manual pages in the
> intro-sections is not enough.
>
> For example [...]
>
> Another option could
On Mon, May 17, 2010 at 07:35:37PM +0200, Matthias Drochner wrote:
> Also, the xrefs are not sorted strictly alphabetically but
> in some logical order which is good imo.
The Xrefs are generally a symptom of the manual page format. As D. Holland
well said, the "man -k is so 1980s".
In my opinion
> Is the SEE ALSO section meant to refer to external sources?
Just as a data point, OSF/1 does this.
To cite eg inet(7):
RELATED INFORMATION
Functions: ioctl(2), socket(2).
Network Information: netintro(7), tcp(7), udp(7), ip(7), icmp(7).
Network Programmer's Guide
Technical Overview
R
On Mon, May 17, 2010 at 09:21:18AM +0200, Marc Balmer wrote:
> Is the SEE ALSO section meant to refer to external sources? I always
> thought it was only to reference other manpages.
I don't know if there has ever been a strict rule about this; even some of
the really old manual pages refer to ex
Am 16.05.10 14:23, schrieb Jukka Ruohonen:
> Module Name: src
> Committed By: jruoho
> Date: Sun May 16 12:23:32 UTC 2010
>
> Modified Files:
> src/lib/libpthread: pthread.3
>
> Log Message:
> Add the Butenhof's book to SEE ALSO. (It was decent enough when I read it
> years ago, bu
On 3/24/10 7:32 PM, enami tsugutomo wrote:
> The _lwp_ctl() call also need to be called with &self->pt_lwpctl
> doesn't it?
I thought pthread__first would be the same as pthread__self() here, but
when I just used pthread__first rather than calling pthread__self() I
got a different value.
I don't
> Modified Files:
> src/lib/libpthread: pthread.c
>
> Log Message:
> fix the pthread pt_lid in the fork callback function that runs in the child=
> instead of a function that may be going away. KNFify
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.114 -r1.115 src/lib/libpthr
On Sun, 29 Mar 2009 09:30:05 +
Andrew Doran wrote:
> Module Name: src
> Committed By: ad
> Date: Sun Mar 29 09:30:05 UTC 2009
>
> Modified Files:
> src/lib/libpthread: pthread.c
> src/lib/libpthread/arch/i386: pthread_md.c pthread_md.h
>
> Log Message:
> - Make the thre
91 matches
Mail list logo
