Re: vfork() and posix_spawn() [was: Re: CVS commit: src/lib/libc/sys]
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 that, and I know very little about threads. | On the specific topic, I'm somewhat puzzled by the claim that fork is | async-signal-safe That's not what I said, I said it isn't (though the way I phrased that might not have been all that clear - I know I often type too much, and sometimes overcompensate by typing too little). But (from my message): If the "that said" relates to fork() or vfork() not being async signal safe, so a double fork() (when the first is vfork anyway) would not be condoned, was meant to acknowledge that fork() (and vfork()) aren't async signal safe, and so if a requirement that async signal safe functions are all that is permitted after vfork() actually existed, then a if (vfork() == 0) fork(); sequence would not be permitted (not generate defined actions). But for the purposes of whether double fork() option to posix_spawn is useful or not, this restriction doesn't matter, as the above can be (eventually) written if (vfork() == 0) _Fork(); instead, as _Fork() is (to be) async signal safe. Same effect as the (perhaps) undefined version above for this purpose. | since most implementations will require synchronisation for pthread_atfork Yes, which is what _Fork() does not do (_Fork() is to fork() as _exit() is to exit() - in a sense). | It most likely should. The main reason is that much of the system can | and often do depend on things like mutexes to ensure correctness and all | that is essentially UB after vfork(). Actually, it isn't UB, or shouldn't be. The behaviour of vfork() is actually very precisely specified (which doesn't take much, as it is quite simple). There's very little room for UB. What there is is plenty of room for simple errors to screw things (and appear as if it is UB, when it is actually quite well defined broken code). There's no problem using mutexes after a vfork() with two caveats - first anything locked must be unlocked again before the eventual _exit() or exec() (the mutex must be returned to its state at the time of the vfork()) and the child must not need to lock anything which might be already locked in the parent (as that's a guaranteed deadlock). How one makes the latter condition work is for someone else to solve... That said, most of what would require a mutex isn't something that should be being done after a vfork() anyway - most of those operations are likely to be things which change state of the process, and that's what (at least without careful preparation) cannot happen in a child of a vfork() (so no use of stdio, no use of malloc, ...) | That's even ignoring the stronger issue of mutating state. Yes, though if it is intentional, that can actually be OK (sometimes). Our /bin/sh relies upon the ability to modify its parent's state after a vfork() to communicate status back to the parent (more than is possible reliably with exit status - as the parent cannot tell from that whether the status it receives is from its own image running the child after the vfork() or from some other process after an exec() succeeded). A modified volatile variable (in the parent), however, can only have been modified by the vfork() child (we assume here that the parent isn't modifying the variable itself elsewhere, naturally). And yes, that means that on any system that "implements" vfork() using cc -Dvfork=fork (or its equivalent) cannot use vfork() with our sh - we need a "real" vfork, or must simply disable its use and only use fork (which is what the -D implementation does anyway of course, just badly). | vfork use really should die... That sentiment has been around for a long time - almost since vfork() was first created (40+ years ago). But it is still here. Implementing fork() using CoW was supposed to solve all the issues with fork(). It didn't, vfork() is still lots faster. posix_spawn() might allow some uses of vfork()+exec() to be retired, that would be good, but it isn't going to get all of them. | No, it relates to one common pattern for used by or for daemon. Yes, I understood that, but why do we care? Daemons start how often? What percentage of the forks() (vfork is, in practice, never used for this) on your systems are generated by daemons starting? What kind of saving would you expect to see from allowing posix_spawn() to replace that fork();fork() sequence ? Is it really worth even the tiniest extra complexity in that already fairly complex interface to handle this almost irrelevant issue? Do you believe in non-memory managed real time systems there are any daemon processes like that at all? | There are non-trivial uses of fork, yes. There are much less no
Re: vfork() and posix_spawn() [was: Re: CVS commit: src/lib/libc/sys]
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 at 01:03:20AM +0700, Robert Elz wrote: > | > after a vfork() the child can do anything > > | This is not true. After vfork(), it is only supposed to call async > | signal safe functions. > > What you said, and what I said are not contradictory. Note I said "can > do" and you said "is only supposed to". > > What is supposed to work and what actually does work (or can be made to > work) are two different things. Sure, but the set of what works reliably has actually been shrinking over time and more bugs in various programs using vfork specifically have been discovered. This is even more true for multi-threaded applications (where POSIX explicitly suggests that requirement). On the specific topic, I'm somewhat puzzled by the claim that fork is async-signal-safe since most implementations will require synchronisation for pthread_atfork and that seems to place quite a burden on the implementation... > I would note though our man page doesn't make that requirement, or not > that I can see anyway, and vfork() is not in POSIX of course - and while > I don't have a copy to check, I'd suspect not in the C standards either), > so while that sounds like a reasonable requirement to impose for safer > operation, I'm not sure that anyone or anything actually does that. It most likely should. The main reason is that much of the system can and often do depend on things like mutexes to ensure correctness and all that is essentially UB after vfork(). That's even ignoring the stronger issue of mutating state. vfork use really should die... > > | That said, a flag for the double fork semantic might be useful. > > If the "that said" relates to fork() or vfork() not being async signal safe, > so a double fork() (when the first is vfork anyway) would not be condoned, > that doesn't matter, there to be an async-signal-safe _Fork() call added to > the next version of POSIX, so even with the "only async signal safe" > requirement for vfork() a: No, it relates to one common pattern for used by or for daemon. > Please don't see posix_spawn() as being (or ever becoming) a panacea that > can replace all fork() (or even just vfork()) calls - even just in the > cases where an exec() follows soon after. It works fine for most simple > cases, but there are lots of not-so-simple situations that it cannot handle, > and burdening the interface with the ability to deal with all of those > would reduce the "efficiently implementable" goal for little real benefit. There are non-trivial uses of fork, yes. There are much less non-trivial uses of vfork as the latter already has quite a few problems with spooky actions otherwise. Supporting something like a double fork flag has very little impact on the complexity of the implementation and even less impact on the efficiency. We certainly are at the point where we can start analyzing the remaining blockers for (v)fork+exec users. > Another example is made obvious by the bug Martin committed a fix for > in the past few days ... the order of operations was incorrect in our > implementation. But that this problem can exist shows that there > are ordering issues - a process that wants to open files using its > current privs, then reset those before (perhaps) opening more files, > and then doing the exec() part cannot do that with posix_spawn(). > Again, this is rare enough that adding the complexity required to allow > it to work just isn't worth it. [In this area also note that the > POSIX_SPAWN_RESETIDS flag causes (effectively) setuid(getuid()), there's > no similar operation to do setuid(geteuid()) ... again too rare to bother.] I quite disagree here, actually. The design-level issue is that POSIX_SPAWN_RESETIDS is a flag and not an action. This means it can't be sequenced and that is the reason for the limitation. There is an obvious parallel with the semantics of the chdir action here--that needs to be that, an action and not just a flag. The separate concern is of course that we need more testing for posix_spawn, but that is hopefully also going to become better as side effect of the non-GSoC project. Joerg
vfork() and posix_spawn() [was: Re: CVS commit: src/lib/libc/sys]
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 anything
| This is not true. After vfork(), it is only supposed to call async
| signal safe functions.
What you said, and what I said are not contradictory. Note I said "can
do" and you said "is only supposed to".
What is supposed to work and what actually does work (or can be made to
work) are two different things.
I would note though our man page doesn't make that requirement, or not
that I can see anyway, and vfork() is not in POSIX of course - and while
I don't have a copy to check, I'd suspect not in the C standards either),
so while that sounds like a reasonable requirement to impose for safer
operation, I'm not sure that anyone or anything actually does that.
| That said, a flag for the double fork semantic might be useful.
If the "that said" relates to fork() or vfork() not being async signal safe,
so a double fork() (when the first is vfork anyway) would not be condoned,
that doesn't matter, there to be an async-signal-safe _Fork() call added to
the next version of POSIX, so even with the "only async signal safe"
requirement for vfork() a:
if ((child = vfork()) == 0) {
if (_Fork())_exit(0);
/* do child stuff here */
} else {
if (child != -1) waitpid(child, &status, 0);
/* parent continues */
}
sequence is possible (will be possible, we don't have _Fork() yet)
and fully conforming, apart from vfork() not being in the standard.
The child of the vfork() only does _Fork() and _exit(), both of which
are permitted. The grandchild process is created by a full fork() so
can do anything at all.
For what it is worth, the definition of _Fork() is (to be):
The _Fork() function shall be equivalent to fork(), except
that fork handlers established by means of the pthread_atfork()
function shall not be called and _Fork() shall be async-signal-safe.
Aside from the prototype line, which is just as you'd expect, that's it.
If (or when) we add it, we probably need to decide whether we need _VFork()
(or some similar name) as well. Probably.
However, an extra posix_spawn attribute to handle double fork is almost
certainly not warranted, this kind of thing isn't all that common, and
adding the mechanism to the posix_spawn set of functions would really
just be bloat (there's also a proposal floating around to add the
ability to change a terminal's process group as a posix_spawn action --
that's required for shells to be able to use posix_spawn in general cases,
but that most likely won't go anywhere).
Remember what the standard says about posix_spawn() (in its rationale, this
is not strictly part of the standard)...
The posix_spawn( ) function and its close relation posix_spawnp( )
have been introduced to overcome the following perceived difficulties
with fork( ): the fork( ) function is difficult or impossible to
implement without swapping or dynamic address translation.
[...]
This view of the role of posix_spawn( ) and posix_spawnp( ) influenced
the design of their API. It does not attempt to provide the full
functionality of fork( )/exec in which arbitrary user-specified
operations of any sort are permitted between the creation of the
child process and the execution of the new process image; any attempt
to reach that level would need to provide a programming language as
parameters.
[...]
[ It lists some of the known problems with the posix_spawn interface ]
[...]
The posix_spawn( ) and posix_spawnp( ) functions do not have all the
power of fork( )/exec. This is to be expected. The fork( ) function
is a wonderfully powerful operation. We do not expect to duplicate
its functionality in a simple, fast function with no special hardware
requirements. It is worth noting that posix_spawn( ) and
posix_spawnp( ) are very similar to the process creation operations
on many operating systems that are not UNIX systems.
It then goes on to list the requirements they had for posix_spawn()...
The requirements for posix_spawn( ) and posix_spawnp( ) are:
� They must be implementable without an MMU or unusual hardware.
� They must be compatible with existing POSIX standards.
Additional goals are:
� They should be efficiently implementable.
� They should be able to replace at least 50% of typical
executions of fork( ).
� A system with posix_spawn( ) and posix_spawnp( ) and without
fork( ) should be useful, at least for realtime applications.
Re: CVS commit: src/lib/libc/sys
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 it can) posix_spawn() isn't > nearly that general, it just handles the most common things apps > are likely to want to do between the fork() and exec(). This is not true. After vfork(), it is only supposed to call async signal safe functions. That said, a flag for the double fork semantic might be useful. Joerg
Re: CVS commit: src/lib/libc/sys
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 vfork().
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 it can) posix_spawn() isn't
nearly that general, it just handles the most common things apps
are likely to want to do between the fork() and exec(). Perhaps
most notably, it has no notion of (with err checking omitted):
if (fork()) { parent_code(/* do a waitpid() first */); }
else if (fork()) { exit(0); }
else { child_code() /* often ending with execX() */ }
when one wants to create an orphan (nothing that cannot be waited upon).
kre
Re: CVS commit: src/lib/libc/sys
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 message in, not pass the name of the file! christos
Re: CVS commit: src/lib/libc/sys
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 obsolete PT_LWPINFO.
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.82 -r1.83 src/lib/libc/sys/ptrace.2
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>
>
> Modified files:
>
> Index: src/lib/libc/sys/ptrace.2
> diff -u src/lib/libc/sys/ptrace.2:1.82 src/lib/libc/sys/ptrace.2:1.83
> --- src/lib/libc/sys/ptrace.2:1.82Wed Oct 9 14:20:47 2019
> +++ src/lib/libc/sys/ptrace.2 Sat Jan 4 04:40:17 2020
> @@ -1,7 +1,7 @@
> -.\" $NetBSD: ptrace.2,v 1.82 2019/10/09 14:20:47 wiz Exp $
> +.\" $NetBSD: ptrace.2,v 1.83 2020/01/04 04:40:17 kamil Exp $
> .\"
> .\" This file is in the public domain.
> -.Dd October 9, 2019
> +.Dd January 4, 2019
> .Dt PTRACE 2
> .Os
> .Sh NAME
> @@ -399,7 +399,7 @@ argument should contain the name of the
> and the
> .Fa data
> argument should contain the length of the core filename.
> -.It Dv PT_LWPINFO
> +.It Dv PT_LWPSTATUS
> Returns information about a thread from the list of threads for the
> process specified in the
> .Fa pid
> @@ -407,41 +407,50 @@ argument.
> The
> .Fa addr
> argument should contain a
> -.Vt struct ptrace_lwpinfo
> +.Vt struct ptrace_lwpstatus
> defined as:
> .Bd -literal -offset indent
> -struct ptrace_lwpinfo {
> +struct ptrace_lwpstatus {
> lwpid_t pl_lwpid;
> - int pl_event;
> + sigset_t pl_sigpend;
> + sigset_t pl_sigmask;
> + char pl_name[20];
> + void *pl_private;
> };
> .Ed
> .Pp
> where
> .Fa pl_lwpid
> contains a thread LWP ID.
> -Information is returned for the thread following the one with the
> +Information is returned for the thread specified in
> +.Fa pl_lwpid .
> +.Fa pl_sigpend
> +contains the signals pending on that LWP.
> +.Fa pl_sigmask
> +contains the signals masked on that LWP.
> +.Fa pl_name
> +contains printable name of the LWP.
> +The string is always NUL terminated.
> +.Fa pl_private
> +contains the pointer to TLS base.
> +.Pp
> +The
> +.Fa data
> +argument should contain
> +.Dq Li sizeof(struct ptrace_lwpinfo) .
> +.It Dv PT_LWPNEXT
> +Is the same as
> +.Dv PT_LWPSTATUS ,
> +except that information is returned for the thread following the one with the
> specified ID in the process thread list, or for the first thread
> if
> .Fa pl_lwpid
> is 0.
> +.Pp
> Upon return
> .Fa pl_lwpid
> contains the LWP ID of the thread that was found, or 0 if there is
> no thread after the one whose LWP ID was supplied in the call.
> -.Fa pl_event
> -contains the event that stopped the thread.
> -Possible values are:
> -.Pp
> -.Bl -tag -width 30n -offset indent -compact
> -.It Dv PL_EVENT_NONE
> -.It Dv PL_EVENT_SIGNAL
> -.It Dv PL_EVENT_SUSPENDED
> -.El
> -.Pp
> -The
> -.Fa data
> -argument should contain
> -.Dq Li sizeof(struct ptrace_lwpinfo) .
> .It Dv PT_SYSCALL
> Stops a process before and after executing each system call.
> Otherwise this operation is the same as
> @@ -987,10 +996,3 @@ to
> .Fn ptrace
> .Ec ,
> should be able to sidestep this.
> -.Pp
> -.Dv PT_SET_SIGINFO ,
> -.Dv PT_RESUME
> -and
> -.Dv PT_SUSPEND
> -can change the image of process returned by
> -.Dv PT_LWPINFO .
>
signature.asc
Description: OpenPGP digital signature
Re: CVS commit: src/lib/libc/sys
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 into > | > the same manual pages. > | > | Where did you get that impression? > > Good question - Kamil, see: > man 2 wait > for a counter example (there are many.) > > kre > I learnt it from this thraed: List: netbsd-tech-userlevel Subject:Re: reallocarr(3) cleanup From: David Holland Date: 2015-03-18 0:07:45 Message-ID: 20150318000745.GB15136 () netbsd ! org [Download message RAW] On Wed, Mar 18, 2015 at 12:00:51AM +0100, Joerg Sonnenberger wrote: > On Tue, Mar 17, 2015 at 11:56:35PM +0100, Kamil Rytarowski wrote: > > - merge reallocarr.3 to malloc.3 for consistency, > > No. Don't put standard and non-standard functions in the same man page. concur -- David A. Holland dholl...@netbsd.org https://marc.info/?l=netbsd-tech-userlevel&m=142663727209791&w=2 signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/lib/libc/sys
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 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 functions into >> the same manual pages. > >Where did you get that impression? I think that the current practice (and usefulness) of putting families of functions together in the same man page far exceeds the value of having POSIX only man pages. >> Currently there is no man-page link accept4 -> accept. > >Yes, that needs to be fixed with another MLINS+= I fixed that. christos
Re: CVS commit: src/lib/libc/sys
> 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) > and paccept(2). > > Since we are here - are we planning to introduce ppoll(2)? It's very > similar to homegrown pollts(2). Porting of it is the same scenario to > accept4(2). The poll(2) man page, documenting both poll and pollts, appears to be a counterexample to the rule you just stated! I don't see a problem with this. We can have a section STANDARDS for describing which one is which. (We perhaps also ought to specify in the synopsis what feature symbols make it available.)
Re: CVS commit: src/lib/libc/sys
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 you get that impression? Good question - Kamil, see: man 2 wait for a counter example (there are many.) kre
Re: CVS commit: src/lib/libc/sys
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: > > Document accept4 in accept(2) > > In general we don't put POSIX/standard and nonstandard functions into > the same manual pages. Where did you get that impression? > Currently there is no man-page link accept4 -> accept. Yes, that needs to be fixed with another MLINS+= -uwe
Re: CVS commit: src/lib/libc/sys
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 functions into the same manual pages. I think accept(2) should be split with accept4(2) and paccept(2). Currently there is no man-page link accept4 -> accept. Since we are here - are we planning to introduce ppoll(2)? It's very similar to homegrown pollts(2). Porting of it is the same scenario to accept4(2). codesearch.debian.net gives 233 packages for accept4(2) and 191 for ppoll(2) signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/lib/libc/sys
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 those things next time. To generate a diff of this commit: cvs rdiff -u -r1.28 -r1.29 src/lib/libc/sys/bind.2 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
re: CVS commit: src/lib/libc/sys
> 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.
Re: CVS commit: src/lib/libc/sys
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) specific errors" Fixed in repository. > To generate a diff of this commit: > cvs rdiff -u -r1.30 -r1.31 src/lib/libc/sys/readlink.2 > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. -- Nicolas Joly Biology IT Center Institut Pasteur, Paris.
Re: CVS commit: src/lib/libc/sys
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: sched.c
> >
> > Log Message:
> > fail as the man page says sched_rr_get_interval should.
>
> #include
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -123,6 +124,8 @@ int
> sched_rr_get_interval(pid_t pid, struct timespec *interval)
> {
>
> + if (pid && kill(pid, 0) == -1)
> + return -1;
> interval->tv_sec = 0;
> interval->tv_nsec = sysconf(_SC_SCHED_RT_TS) * 1000;
> return 0;
>
> So to return to this: surely this can't be right?
>From the kill man page:
sig may be one of the signals specified in sigaction(2) or it may be
0, in which case error checking is performed but no signal is actually
sent.
Thomas
Re: CVS commit: src/lib/libc/sys
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
#include
#include
#include
+#include
#include
#include
@@ -123,6 +124,8 @@ int
sched_rr_get_interval(pid_t pid, struct timespec *interval)
{
+ if (pid && kill(pid, 0) == -1)
+ return -1;
interval->tv_sec = 0;
interval->tv_nsec = sysconf(_SC_SCHED_RT_TS) * 1000;
return 0;
So to return to this: surely this can't be right?
- Jukka.
Re: CVS commit: src/lib/libc/sys
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.
Re: CVS commit: src/lib/libc/sys
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. > And what if it is open already?? it gets closed first. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/lib/libc/sys
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. What happens if the 'new' file number is above RLIMIT_NOFILES? And what if it is open already?? David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/lib/libc/sys
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 required convention now? ISTM that quite a few pages have > or had the same errno listed more than once, usually for logically > separate conditions. It's the one to which I've been converting files I've touched for quite some time now. I think it's easier to see all reasons for an error code when you look up the error code and wouldn't expect multiple entries for the same error code in the list. (Especially since sometimes they aren't even next to each other, where one might see them by reading on.) Thomas
Re: CVS commit: src/lib/libc/sys
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 listed more than once, usually for logically separate conditions. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/lib/libc/sys
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, yet another slightly-different variant to cause confusion. I don't suppose their new invention is the same as (or even compatible with) the utime() we already have that's marked obsolete? > So I guess the *at() thing strikes again. Apparently. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/lib/libc/sys
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, the utime() function should be used to set file access and modification times instead of utimes()." FUTURE DIRECTIONS This function may be withdrawn in a future version. 2008: "The utimes() function shall be equivalent to the utimensat() function with the special value AT_FDCWD as the fd argument and the flag argument set to zero, except that the times argument is a timeval structure rather than a timespec structure, and accuracy is only to the microsecond, not nanosecond, and rounding towards the nearest second may occur." So I guess the *at() thing strikes again. - Jukka.
Re: CVS commit: src/lib/libc/sys
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
Re: CVS commit: src/lib/libc/sys
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 already? > > > IMO, the use-once stream is a too common workload to require > > an explicit hint. the VM should just handle it nicely without hints. > > If you copy a large directory tree for example, you want to ensure that > writing starts early and is done continious. This is something were the > hint helps (as opposed to writing a file for later use, even if it is > done sequentially). Oh, on write... yeah, in that case, this. -- Dan. pgpdaCQr6uL6T.pgp Description: PGP signature
Re: CVS commit: src/lib/libc/sys
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 by whatever caching scheme is in use. Normally, every hit counts for something, and is a clue about further possible activity (or lack thereof, if the predictor is smart enough). The hint is an extra clue, and seems pretty close to directly saying "ignore this next access" without otherwise needing to complicate the predictor. > IMO, the use-once stream is a too common workload to require > an explicit hint. the VM should just handle it nicely without > hints. Agreed, and there are caching schemes that do cope well with this; ZFS promoters make much of ARC's capability in this specifically, along with their prefetching scheme. -- Dan. pgpO3bt7q44Ke.pgp Description: PGP signature
Re: CVS commit: src/lib/libc/sys
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 explicit hint. the VM should just handle it nicely without hints. If you copy a large directory tree for example, you want to ensure that writing starts early and is done continious. This is something were the hint helps (as opposed to writing a file for later use, even if it is done sequentially). Joerg
Re: CVS commit: src/lib/libc/sys
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 very helpful for things like tar and cp > to reduce buffer cache pressure. > > Joerg i want to implement them if useful. do you have any idea what an implementation of POSIX_FADV_NOREUSE which is not a no-op would be like? IMO, the use-once stream is a too common workload to require an explicit hint. the VM should just handle it nicely without hints. i have to admit that i have no idea what NOREUSE hint can optimize it further. YAMAMOTO Takashi
Re: CVS commit: src/lib/libc/sys
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 things like tar and cp to reduce buffer cache pressure. Joerg
Re: CVS commit: src/lib/libc/sys
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/scsictl. > > Bump date. (first time since 1993!) > > Thanks, however: > > +.Sh CAUTIONS > +Many modern disks contain write-back caches. > +In theory > +.Fn sync > +flushes these. > > This is not true, unless you are using logging (or zfs!). It should be true; why is it not? Does this need to be moved under BUGS? > +In practice there are many possible ways for this mechanism to go > +astray. > +It is prudent (where possible) to allow a few seconds after syncing > +for everything to settle before e.g. turning off the power. > +.Pp > +It may also be desirable to use > +.Xr dkctl 8 > +or > +.Xr scsictl 8 > +to disable the write-back cache entirely. > > This is wishy washy. It gives the sense that we know there is a problem, but > simply couldn't be arsed fixing it. What do you want to convey? Should we have a list of filesystems and whether they work properly? Crossreferences to mount_foo(8) for all foo? Or should it just contain Kirk's advice, that is, people who care about their data shouhld always disable the write-back cache? -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/lib/libc/sys
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. > Bump date. (first time since 1993!) Thanks, however: +.Sh CAUTIONS +Many modern disks contain write-back caches. +In theory +.Fn sync +flushes these. This is not true, unless you are using logging (or zfs!). +In practice there are many possible ways for this mechanism to go +astray. +It is prudent (where possible) to allow a few seconds after syncing +for everything to settle before e.g. turning off the power. +.Pp +It may also be desirable to use +.Xr dkctl 8 +or +.Xr scsictl 8 +to disable the write-back cache entirely. This is wishy washy. It gives the sense that we know there is a problem, but simply couldn't be arsed fixing it. What do you want to convey?
Re: CVS commit: src/lib/libc/sys
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* embarrassing mistake. Or something... anyway. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/lib/libc/sys
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 spelling alright, but the ordering in SEE ALSO has section first, name second... Thomas
