Re: CVS commit: src/lib/libpthread

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:

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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:

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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 >

Re: CVS commit: src/lib/libpthread

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:

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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.

Re: CVS commit: src/lib/libpthread

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. >

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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.

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

And it is fixed now. christos signature.asc Description: Message signed with OpenPGP

Re: CVS commit: src/lib/libpthread

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:

Re: CVS commit: src/lib/libpthread

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 >

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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: CVS commit: src/lib/libpthread

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:

Re: CVS commit: src/lib/libpthread

> 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

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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 you

Re: CVS commit: src/lib/libpthread

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 pthread.h class foo { pthread_mutex_t m; public:

Re: CVS commit: src/lib/libpthread

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.php?id=4110

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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 started work on

Re: CVS commit: src/lib/libpthread

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_types.h

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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:

Re: CVS commit: src/lib/libpthread

This is the simplest program to repeat the problem with g++ 5.1 and NetBSD's pthread_types.h: #include pthread.h 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

Re: CVS commit: src/lib/libpthread

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 libstdc++, I

Re: CVS commit: src/lib/libpthread

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 pthread.h class foo { pthread_mutex_t m; public: constexpr foo() : m(PTHREAD_MUTEX_INITIALIZER) {} }; (plus

Re: CVS commit: src/lib/libpthread

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,

Re: CVS commit: src/lib/libpthread

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++)

Re: CVS commit: src/lib/libpthread

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 as a

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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 release of

Re: CVS commit: src/lib/libpthread

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 as a

Re: CVS commit: src/lib/libpthread

In article 20141217014908.359b...@cvs.netbsd.org, Antti Kantee source-changes-d@NetBSD.org 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

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

In article 20130401132606.8cc2997...@rebar.astron.com, Christos Zoulas chris...@zoulas.com 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.

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) | 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 changed the

Re: CVS commit: src/lib/libpthread

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) | | binaries built on 6.1

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) | | binaries built on 6.1 silently fails on 6.0.1. | | It was a mistake, we should have bumped. | | Note, that bumping would

Re: CVS commit: src/lib/libpthread

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 write the rules

Re: CVS commit: src/lib/libpthread

| 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 fixes)

Re: CVS commit: src/lib/libpthread

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 pthread fixes) I

Re: CVS commit: src/lib/libpthread

In article 20130329032804.23b1514a...@mail.netbsd.org, YAMAMOTO Takashi y...@mwd.biglobe.ne.jp 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

Re: CVS commit: src/lib/libpthread

In article 20130329032804.23b1514a...@mail.netbsd.org, YAMAMOTO Takashi y...@mwd.biglobe.ne.jp 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

Re: CVS commit: src/lib/libpthread

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)

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 I can put a cross-reference to it. http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_key_delete.html It is the

Re: CVS commit: src/lib/libpthread

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 I can put

Re: CVS commit: src/lib/libpthread

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}etspecific

Re: CVS commit: src/lib/libpthread

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 threads when

Re: CVS commit: src/lib/libpthread

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 set.

Re: CVS commit: src/lib/libpthread

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 Message: Only

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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/libpthread: pthread.h pthread_attr.c

Re: CVS commit: src/lib/libpthread

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 functions

Re: CVS commit: src/lib/libpthread

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 be a

Re: CVS commit: src/lib/libpthread

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 we

Re: CVS commit: src/lib/libpthread

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, but if

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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

Re: CVS commit: src/lib/libpthread

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