Taylor R Campbell wrote in
<20241221185628.a4efaf...@cvs.netbsd.org>:
|Module Name: src
|Committed By: riastradh
|Date: Sat Dec 21 18:56:28 UTC 2024
|
|Modified Files:
| src/lib/libc/sys: close.2
|
|Log Message:
|close(2): Document the finality of closing.
|
|Even if close(2) r
Date:Mon, 14 Jun 2021 03:56:48 +0200
From:Joerg Sonnenberger
Message-ID:
| This is even more true for multi-threaded applications
| (where POSIX explicitly suggests that requirement).
Sure, anything with fork() and threads has issues, that's messy.
Even I know t
On Mon, Jun 14, 2021 at 01:33:51AM +0700, Robert Elz wrote:
> Date:Sat, 12 Jun 2021 23:13:54 +0200
> From:Joerg Sonnenberger
> Message-ID:
>
> Sorry, missed this message when I was cherry picking messages to read in
> a timely fashion.
>
> | On Wed, Jun 09, 2021 a
Date:Sat, 12 Jun 2021 23:13:54 +0200
From:Joerg Sonnenberger
Message-ID:
Sorry, missed this message when I was cherry picking messages to read in
a timely fashion.
| On Wed, Jun 09, 2021 at 01:03:20AM +0700, Robert Elz wrote:
| > after a vfork() the child can do
On Wed, Jun 09, 2021 at 01:03:20AM +0700, Robert Elz wrote:
> It should, when it is workable for the application, make things
> faster, while also avoiding the vfork() perils. But only when
> it works -- after a vfork() the child can do anything (it should
> avoid touching its parent's state, but
Date:Tue, 8 Jun 2021 16:15:12 +
From:"Nia Alarie"
Message-ID: <20210608161512.1d7c3f...@cvs.netbsd.org>
| vfork.2: recommend posix_spawn instead
You might want to reconsider the wording there, posix_spawn() is
an alternative to [v]fork() + exec*(). Not just v
In article <20200104044017.c44aef...@cvs.netbsd.org>,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: kamil
>Date: Sat Jan 4 04:40:17 UTC 2020
>
>Modified Files:
> src/lib/libc/sys: ptrace.2
>
>Log Message:
>/tmp/cvsbigmGa
You need to read the commit mes
On 04.01.2020 05:40, Kamil Rytarowski wrote:
> Module Name: src
> Committed By: kamil
> Date: Sat Jan 4 04:40:17 UTC 2020
>
> Modified Files:
> src/lib/libc/sys: ptrace.2
>
> Log Message:
> /tmp/cvsbigmGa
>
Document PT_LWPSTATUS and PT_LWPNEXT in ptrace(2)
Remove mentions of o
On 23.02.2017 12:33, Robert Elz wrote:
> Date:Thu, 23 Feb 2017 13:48:10 +0300
> From:Valery Ushakov
> Message-ID: <20170223104810.gw20...@pony.stderr.spb.ru>
>
> | > From: Kamil Rytarowski
> | > In general we don't put POSIX/standard and nonstandard functions i
In article <20170223104810.gw20...@pony.stderr.spb.ru>,
Valery Ushakov wrote:
>On Thu, Feb 23, 2017 at 10:12:25 +0100, Kamil Rytarowski wrote:
>
>> On 08.02.2017 19:01, Maya Rashish wrote:
>> > Module Name: src
>> > Committed By: maya
>> > Date: Wed Feb 8 18:01:24 UTC 201
> Date: Thu, 23 Feb 2017 10:12:25 +0100
> From: Kamil Rytarowski
>
> On 08.02.2017 19:01, Maya Rashish wrote:
> > Document accept4 in accept(2)
>
> In general we don't put POSIX/standard and nonstandard functions into
> the same manual pages. I think accept(2) should be split with accept4(2)
> a
Date:Thu, 23 Feb 2017 13:48:10 +0300
From:Valery Ushakov
Message-ID: <20170223104810.gw20...@pony.stderr.spb.ru>
| > From: Kamil Rytarowski
| > In general we don't put POSIX/standard and nonstandard functions into
| > the same manual pages.
|
| Where did y
On Thu, Feb 23, 2017 at 10:12:25 +0100, Kamil Rytarowski wrote:
> On 08.02.2017 19:01, Maya Rashish wrote:
> > Module Name:src
> > Committed By: maya
> > Date: Wed Feb 8 18:01:24 UTC 2017
> >
> > Modified Files:
> > src/lib/libc/sys: accept.2
> >
> > Log Message:
On 08.02.2017 19:01, Maya Rashish wrote:
> Module Name: src
> Committed By: maya
> Date: Wed Feb 8 18:01:24 UTC 2017
>
> Modified Files:
> src/lib/libc/sys: accept.2
>
> Log Message:
> Document accept4 in accept(2)
>
In general we don't put POSIX/standard and nonstandard funct
somehow i knew this was coming :)
On 4/5/2015 4:41 PM, Thomas Klausner wrote:
Module Name:src
Committed By: wiz
Date: Sun Apr 5 20:41:06 UTC 2015
Modified Files:
src/lib/libc/sys: bind.2
Log Message:
Sort errors. Bump date for previous.
thanks i'll try to catch thos
> XXX Do we not guarantee page-granularity inheritance? Cursory glance
> at uvm suggests we do -- can we nix the caveats about regions vs
> pages?
i think so, i had meant to make the same comment while looking at
this yesterday.
.mrg.
On Sun, Jul 28, 2013 at 09:24:12PM +, Nicolas Joly wrote:
> Module Name: src
> Committed By: njoly
> Date: Sun Jul 28 21:24:12 UTC 2013
>
> Modified Files:
> src/lib/libc/sys: readlink.2
>
> Log Message:
> Add readlink(2) specific errors.
Should have been "Add readlinkat(2) sp
On Sun, Mar 18, 2012 at 08:37:20PM +0200, Jukka Ruohonen wrote:
> On Sat, Mar 17, 2012 at 10:04:40PM -0400, Christos Zoulas wrote:
> > Module Name:src
> > Committed By: christos
> > Date: Sun Mar 18 02:04:40 UTC 2012
> >
> > Modified Files:
> > src/lib/libc/sys: sch
On Sat, Mar 17, 2012 at 10:04:40PM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Sun Mar 18 02:04:40 UTC 2012
>
> Modified Files:
> src/lib/libc/sys: sched.c
>
> Log Message:
> fail as the man page says sched_rr_get_interval should.
#include
On Sat, Jul 16, 2011 at 04:51:41PM +0100, David Laight wrote:
> > Log Message:
> > Note that dup2(2) and dup3(2) may not fail with EMFILE; from PR lib/45148.
>
> What happens if the 'new' file number is above RLIMIT_NOFILES?
It fails with EBADF.
- Jukka.
On Sat, Jul 16, 2011 at 04:51:41PM +0100, David Laight wrote:
> > Modified Files:
> >src/lib/libc/sys: dup.2
> >
> > Log Message:
> > Note that dup2(2) and dup3(2) may not fail with EMFILE; from PR lib/45148.
>
> What happens if the 'new' file number is above RLIMIT_NOFILES?
dunno.
On Sat, Jul 16, 2011 at 02:33:33PM +, Jukka Ruohonen wrote:
> Module Name: src
> Committed By: jruoho
> Date: Sat Jul 16 14:33:33 UTC 2011
>
> Modified Files:
> src/lib/libc/sys: dup.2
>
> Log Message:
> Note that dup2(2) and dup3(2) may not fail with EMFILE; from PR lib/45148.
On Sat, Mar 05, 2011 at 09:14:32PM +, David Holland wrote:
> On Mon, Feb 28, 2011 at 07:17:03AM +, Thomas Klausner wrote:
> > Modified Files:
> >src/lib/libc/sys: mlock.2
> >
> > Log Message:
> > Merge EINVAL descriptions; sort errors alphabetically; bump date.
>
> Is that the re
On Mon, Feb 28, 2011 at 07:17:03AM +, Thomas Klausner wrote:
> Modified Files:
> src/lib/libc/sys: mlock.2
>
> Log Message:
> Merge EINVAL descriptions; sort errors alphabetically; bump date.
Is that the required convention now? ISTM that quite a few pages have
or had the same errno
On Thu, Apr 29, 2010 at 12:05:02PM +0300, Jukka Ruohonen wrote:
> > What's the currently-blessed alternative?
>
> 2004:
>
> APPLICATION USAGE
>
> "For applications portability, the utime() function should be used to set
> file access and modification times instead of utimes()."
oh goody
On Thu, Apr 29, 2010 at 08:51:19AM +, David Holland wrote:
> On Thu, Apr 29, 2010 at 07:14:35AM +, Jukka Ruohonen wrote:
> > Note that utimes(2) no longer enjoys the blessing of POSIX.
>
> What's the currently-blessed alternative?
2004:
APPLICATION USAGE
"For applications portability,
On Thu, Apr 29, 2010 at 07:14:35AM +, Jukka Ruohonen wrote:
> Note that utimes(2) no longer enjoys the blessing of POSIX.
What's the currently-blessed alternative?
--
David A. Holland
dholl...@netbsd.org
On Wed, Jun 10, 2009 at 12:51:58PM +0200, Joerg Sonnenberger wrote:
> On Tue, Jun 09, 2009 at 10:57:16PM +, YAMAMOTO Takashi wrote:
> > do you have any idea what an implementation of POSIX_FADV_NOREUSE
> > which is not a no-op would be like?
>
> Effectively add the page is if has been aged alr
On Tue, Jun 09, 2009 at 10:57:16PM +, YAMAMOTO Takashi wrote:
> i want to implement them if useful.
awesome.
> do you have any idea what an implementation of POSIX_FADV_NOREUSE
> which is not a no-op would be like?
My suggestion would be to not count this hit amongst the statistics
collected
On Tue, Jun 09, 2009 at 10:57:16PM +, YAMAMOTO Takashi wrote:
> do you have any idea what an implementation of POSIX_FADV_NOREUSE
> which is not a no-op would be like?
Effectively add the page is if has been aged already?
> IMO, the use-once stream is a too common workload to require
> an exp
hi,
> On Tue, Jun 09, 2009 at 11:21:34AM +, YAMAMOTO Takashi wrote:
>> Log Message:
>> don't bother to say that some advises are not implemented.
>> ignoring them is a valid implementation.
>
> It should not be under BUGS, but it should still be documented.
> E.g. POSIX_FADV_NOREUSE would be
On Tue, Jun 09, 2009 at 11:21:34AM +, YAMAMOTO Takashi wrote:
> Log Message:
> don't bother to say that some advises are not implemented.
> ignoring them is a valid implementation.
It should not be under BUGS, but it should still be documented.
E.g. POSIX_FADV_NOREUSE would be very helpful for
On Wed, Mar 25, 2009 at 08:58:18AM +, Andrew Doran wrote:
> > Log Message:
> > Update the note about sync returning before buffers are written: it is a
> > piece of historical behavior, not a current bug. Also, while here, add a
> > bit about disk write-back caches and point to dkctl/scsict
On Wed, Mar 25, 2009 at 05:32:52AM +, David A. Holland wrote:
> Log Message:
> Update the note about sync returning before buffers are written: it is a
> piece of historical behavior, not a current bug. Also, while here, add a
> bit about disk write-back caches and point to dkctl/scsictl.
> B
On Wed, Mar 25, 2009 at 09:44:42AM +0100, Thomas Klausner wrote:
> > Oops.
> >
> > Good to know I can spell. Or something.
>
> You were spelling alright, but the ordering in SEE ALSO has section
> first, name second...
Failing to order small integers correctly is not exactly a *less*
embar
On Wed, Mar 25, 2009 at 08:08:04AM +, David Holland wrote:
> On Wed, Mar 25, 2009 at 06:46:21AM +, Thomas Klausner wrote:
> > Modified Files:
> >src/lib/libc/sys: sync.2
> >
> > Log Message:
> > Sort SEE ALSO.
>
> Oops.
>
> Good to know I can spell. Or something.
You were spell
36 matches
Mail list logo
