Re: Replacement for grep(1) (part 2)

nt for there to be a way of allocating address space with no swap reserved *when you specifically ask for it*. Of course I would not disagree with this. Cheers Jon -- \/ Jon Ribbens / j...@oaktree.co.uk To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message

Re: Replacement for grep(1) (part 2)

t, it is an argument for there to be a way of allocating address space with no swap reserved *when you specifically ask for it*. Of course I would not disagree with this. Cheers Jon -- \/ Jon Ribbens / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: Replacement for grep(1) (part 2)

ecomes impossible. So Don't Do That Then. Cheers Jon -- \/ Jon Ribbens / j...@oaktree.co.uk To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message

Re: Replacement for grep(1) (part 2)

"Daniel C. Sobral" wrote: > > I can add it to the list of reasons I don't use it then I guess ;-). > > Whatever. The operating system you use also does it. How terribly tedious. Cheers Jon -- \/ Jon Ribbens / j...@oaktree.co.uk To Unsubscribe: send mail to

Re: Replacement for grep(1) (part 2)

ace, without overcommit it becomes impossible. So Don't Do That Then. Cheers Jon -- \/ Jon Ribbens / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: Replacement for grep(1) (part 2)

"Daniel C. Sobral" <[EMAIL PROTECTED]> wrote: > > I can add it to the list of reasons I don't use it then I guess ;-). > > Whatever. The operating system you use also does it. How terribly tedious. Cheers Jon -- \/ Jon Ribbens / [EMAIL PROTECTED] To

Re: Replacement for grep(1) (part 2)

rcommit'. > If you're not prepared to do that, the long and the short of it is that > FreeBSD _does_ overcommit, we like it that way and neither of these two > facts is likely to change. I can add it to the list of reasons I don't use it then I guess ;-). Cheers Jon -- \

Re: Replacement for grep(1) (part 2)

mory. If FreeBSD *did > not* do it, then you'd need much more memory. Why? Are there really such a lot of applications allocating vastly more memory than they actually use? Cheers Jon -- \/ Jon Ribbens / j...@oaktree.co.uk To Unsubscribe: send mail to majord...@freebsd.org with

Re: Replacement for grep(1) (part 2)

malloc' or 'overcommit'. > If you're not prepared to do that, the long and the short of it is that > FreeBSD _does_ overcommit, we like it that way and neither of these two > facts is likely to change. I can add it to the list of reasons I don't use it then

Re: Replacement for grep(1) (part 2)

*reduces* the need for memory. If FreeBSD *did > not* do it, then you'd need much more memory. Why? Are there really such a lot of applications allocating vastly more memory than they actually use? Cheers Jon -- \/ Jon Ribbens / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAI

Re: Replacement for grep(1) (part 2)

resource limits? > > If the system runs out of memory, the biggest process is killed. It > might or might not be the one demanding additional memory. No, if the *process* hits its *administrative* resource limits. i.e. setrlimit(2). Cheers Jon -- \/ Jon Ribbens / j...@oaktree.co.uk To

Re: Replacement for grep(1) (part 2)

ens if the process hits its resource limits? > > If the system runs out of memory, the biggest process is killed. It > might or might not be the one demanding additional memory. No, if the *process* hits its *administrative* resource limits. i.e. setrlimit(2). Cheers Jon -- \/ Jon Ribben

Re: Replacement for grep(1) (part 2)

"Daniel C. Sobral" wrote: > OTOH, though, FreeBSD's malloc() is very unlikely to return an out > of memory error. Why is that? What happens if the process hits its resource limits? Cheers Jon -- \/ Jon Ribbens / j...@oaktree.co.uk To Unsubscribe: send mail to major

Re: Replacement for grep(1) (part 2)

"Daniel C. Sobral" <[EMAIL PROTECTED]> wrote: > OTOH, though, FreeBSD's malloc() is very unlikely to return an out > of memory error. Why is that? What happens if the process hits its resource limits? Cheers Jon -- \/ Jon Ribbens / [EMAIL PROTECTED] To Unsub