On Fri, Mar 04, 2016 at 11:29:38AM +0100, Dmitrij D. Czarkoff wrote:
> Martijn Dekker said:
> > So this patch makes quoted "$@" act according to the standard even when
> > IFS is empty. Quoted "$*" is unchanged. For the unspecified (not
> > standardised) cases of unquoted $@ and $*, this patch make
> > Even if one day we fix the "browsers problem" in the thread
> > library, I think this diff will remain necessary to handle
> > processes calling sched_yield() in a loop, i.e. processes that are
> > spinning.
> >
> Complete and utter hack: penalize processes or threads on
> #system calls/time p
Tue, 15 Mar 2016 07:10:12 -0600 (MDT) Theo de Raadt
> CVSROOT: /cvs
> Module name: www
> Changes by: dera...@cvs.openbsd.org 2016/03/15 07:10:12
>
> Modified files:
> . : errata57.html errata58.html errata59.html
>
> Log message:
> release new errata
A very insignifi
On 03/23/2016 18:58, Alexandre Ratchov wrote:
On Wed, Mar 23, 2016 at 09:35:50PM +0100, Mark Kettenis wrote:
This doesn't only change the sched_yield() behaviour, but also
modifies how in-kernel yield() calls behave for threaded processes.
That is probably not right.
So here is a diff that ke
On Wed, Mar 23, 2016 at 09:35:50PM +0100, Mark Kettenis wrote:
> >
> > This doesn't only change the sched_yield() behaviour, but also
> > modifies how in-kernel yield() calls behave for threaded processes.
> > That is probably not right.
>
> So here is a diff that keeps yield() the same and adds
On Wed, Mar 23, 2016 at 06:18:59PM -0400, Ted Unangst wrote:
> Mark Kettenis wrote:
> > So here is a diff that keeps yield() the same and adds the code in the
> > sched_yield(2) implementation instead. It also changes the logic that
> > picks the priority to walk the complete threads listand pick
Mark Kettenis wrote:
> So here is a diff that keeps yield() the same and adds the code in the
> sched_yield(2) implementation instead. It also changes the logic that
> picks the priority to walk the complete threads listand pick the
> highest priotity of all the threads. That should be enough to
On 23/03/16(Wed) 21:35, Mark Kettenis wrote:
> > Date: Mon, 21 Mar 2016 16:51:16 +0100 (CET)
> > From: Mark Kettenis
> >
> > > Date: Sat, 19 Mar 2016 13:53:07 +0100
> > > From: Martin Pieuchot
> > >
> > > Applications using multiple threads often call sched_yield(2) to
> > > indicate that one o
> Date: Mon, 21 Mar 2016 16:51:16 +0100 (CET)
> From: Mark Kettenis
>
> > Date: Sat, 19 Mar 2016 13:53:07 +0100
> > From: Martin Pieuchot
> >
> > Applications using multiple threads often call sched_yield(2) to
> > indicate that one of the threads cannot make any progress because
> > it is wait
> Date: Fri, 4 Mar 2016 22:32:19 +0100
> From: Patrick Wildt
>
> Hi,
>
> if you attach sdhc, you automatically compile the pci attachment driver,
> even if there's no "sdhc* at pci?" in the config. This might fail on
> architectures that don't have pci compiled in.
>
> If I'm not completely mi
The current use of in_pcblookup() in in6_pcbconnect() is suboptimal :
all of the addresses and ports are defined, we are only interested in
exact matches, and its v4 cousin in_pcbconnect() already uses
in_pcbhashlookup().
Ok ?
Index: sys/netinet6/in6_pcb.c
amap_extend is called when merging two adjacent areas of virtual address
space. However, merging is done only for kernel
virtual address space. It's not done for user space:
uvm/uvm_map.c:1359
/*
* Try to merge entry.
*
* Userland allocations are kept separated m
On Wed, 23 Mar 2016 10:58:42 -0400, Michael McConville wrote:
> I'm not sure whether avoiding incrementing here is an ideal move, but
> this diff definitely works toward a local optimum. Namely, that error
> check is technically meaningless because signed overflow is undefined.
>
> ok? Or would p
Mark Kettenis wrote:
> > I'm not sure whether avoiding incrementing here is an ideal move, but
> > this diff definitely works toward a local optimum. Namely, that error
> > check is technically meaningless because signed overflow is undefined.
>
> Within the kernel, signed overflow actually is wel
> Date: Wed, 23 Mar 2016 10:58:42 -0400
> From: Michael McConville
>
> I'm not sure whether avoiding incrementing here is an ideal move, but
> this diff definitely works toward a local optimum. Namely, that error
> check is technically meaningless because signed overflow is undefined.
Within the
I'm not sure whether avoiding incrementing here is an ideal move, but
this diff definitely works toward a local optimum. Namely, that error
check is technically meaningless because signed overflow is undefined.
ok? Or would people prefer a solution that's robust to changing
*curpps's type?
Index
On Mon, Mar 21, 2016 at 02:29:46PM +0100, Martin Pieuchot wrote:
> When the caller of arplookup() asked for a proxy'd ARP entry, make
> sure the entry returned by rtalloc(9) is indeed "published".
>
> This is currently always true for ARP entries added with arp(8) but
> it is not the case if you a
Wed, 23 Mar 2016 10:07:10 + skin...@britvault.co.uk (Craig Skinner)
> On 2016-03-22 Tue 22:49 PM |, Bob Beck wrote:
> >
> > A few years back, Ingo moved it to the new mandoc based man.cgi, and
> > now we've actually moved this to a dedicated place - "man.openbsd.org"
>
> Superb. What's next?
On 2016-03-22 Tue 22:49 PM |, Bob Beck wrote:
>
> A few years back, Ingo moved it to the new mandoc based man.cgi, and
> now we've actually moved this to a dedicated place - "man.openbsd.org"
>
Superb.
What's next?
$ ssh gu...@man.openbsd.org
Welcome guest user to OpenBSD's online manual libr
Hi,
first diff that seems to work. Tested on amd64 and compile tested on
sparc64.
It is alo available at http://www.drijf.net/openbsd/malloc
Form the README:
The diff should be applied while in /usr/src/lib, it will patch
both librthreads as as well as libc.
THIS IS WORK IN PROGRESS. It conta
20 matches
Mail list logo