Re: CVS commit: [netbsd-5] src/lib/libpthread

2010-05-20 Thread Soren Jacobsen
On May 20, 2010, at 5:31 PM, Takahiro Kambe wrote:

> In message <20100520050207.9927e17...@cvs.netbsd.org>
>   on Thu, 20 May 2010 05:02:07 +,
>   Soren Jacobsen  wrote:
>> Module Name: src
>> Committed By:snj
>> Date:Thu May 20 05:02:07 UTC 2010
>> 
>> Modified Files:
>>  src/lib/libpthread [netbsd-5]: pthread.c
>> 
>> Log Message:
>> Pull up following revision(s) (requested by explorer in ticket #1353):
>>  lib/libpthread/pthread.c: revision 1.114, 1.115
>> Correctly set pt_lid in the child, after a fork
>> --
>> 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
> 
> I'm very happy with this.
> 
> Should this change be pulled up to netbsd-5-0 branch?

No, just netbsd-5.  At this time, we are being strict, and netbsd-5-0 is only 
getting changes that deserve security advisories.

Re: CVS commit: [netbsd-5] src/lib/libpthread

2010-05-20 Thread Takahiro Kambe
Hi,

In message <20100520050207.9927e17...@cvs.netbsd.org>
on Thu, 20 May 2010 05:02:07 +,
Soren Jacobsen  wrote:
> Module Name:  src
> Committed By: snj
> Date: Thu May 20 05:02:07 UTC 2010
> 
> Modified Files:
>   src/lib/libpthread [netbsd-5]: pthread.c
> 
> Log Message:
> Pull up following revision(s) (requested by explorer in ticket #1353):
>   lib/libpthread/pthread.c: revision 1.114, 1.115
> Correctly set pt_lid in the child, after a fork
> --
> 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
I'm very happy with this.

Should this change be pulled up to netbsd-5-0 branch?

-- 
Takahiro Kambe 


Re: CVS commit: src/sys/rump/librump/rumpkern

2010-05-20 Thread Antti Kantee
On Thu May 20 2010 at 02:47:16 +, David Holland wrote:
> On Tue, May 18, 2010 at 04:29:36PM +, Antti Kantee wrote:
>  > It's pretty obvious that in terms of scalability simple workload
>  > partitioning and replication into multiple kernels wins hands down
>  > over complicated locking or locklessing algorithms which depend on
>  > globally atomic state.
> 
> ...in other breaking news, the sky is blue.

Yet it is not possible everywhere to observe the sky being blue due to
various layers of unnecessary crap.

> :-p :-)

?:-% ('\/)