Re: [hackers] Re: Setting memory allocators for library functions.

2001-02-27 Thread Tony Finch
Peter Seebach [EMAIL PROTECTED] wrote: David Gilbert writes: Due to the bloat of the OS and Motif and other such things, they required simply amazing amounts of swap just to run. Well, to some extent, I have to wonder why all these pages are being requested if they aren't being used... fork()

Re: [hackers] Re: Setting memory allocators for library functions.

2001-02-27 Thread Lyndon Nerenberg
"Tony" == Tony Finch [EMAIL PROTECTED] writes: Well, to some extent, I have to wonder why all these pages are being requested if they aren't being used... Tony fork() with big data segments that cause swap to be reserved Tony in case of a copy-on-write. The 2GB of swap is

Re: [hackers] Re: Setting memory allocators for library functions.

2001-02-27 Thread Tony Finch
Lyndon Nerenberg [EMAIL PROTECTED] wrote: If the information in the data segment is going to be updated then you have to have writable backing store. If, however, that data is never going to be changed, it should be declared in the program as read-only data. The kernel VM system should not be

Re: [hackers] Re: Setting memory allocators for library functions.

2001-02-27 Thread Drew Eckhardt
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes: In most cases it is impossible to declare the data read-only because it originally had to be read-write and you can't change its attributes later. mprotect(2). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe

Re: [hackers] Re: Setting memory allocators for library functions.

2001-02-27 Thread Tony Finch
Drew Eckhardt [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes: In most cases it is impossible to declare the data read-only because it originally had to be read-write and you can't change its attributes later. mprotect(2). If it's available at all, mprotect() is

Re: [hackers] Re: Setting memory allocators for library functions.

2001-02-27 Thread Maxime Henrion
Tony Finch wrote: Drew Eckhardt [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes: In most cases it is impossible to declare the data read-only because it originally had to be read-write and you can't change its attributes later. mprotect(2). If it's

Re: [hackers] Re: Setting memory allocators for library functions.

2001-02-27 Thread Tony Finch
Maxime Henrion [EMAIL PROTECTED] wrote: Tony Finch wrote: If it's available at all, mprotect() is often limited to memory obtained with mmap(), i.e. not malloc(). Not great for portability. FreeBSD malloc() calls mmap() as AFAIK many (if not all) malloc() implementations. FreeBSD malloc()

[hackers] Re: Setting memory allocators for library functions.

2001-02-26 Thread David Gilbert
"Daniel" == Daniel C Sobral [EMAIL PROTECTED] writes: Daniel Dag-Erling Smorgrav wrote: None of these solutions are portable, however; Well, no, but the sole available definition of "portable" says that it is "portable" to assume that all the memory malloc can return is really

Re: [hackers] Re: Setting memory allocators for library functions.

2001-02-26 Thread Peter Seebach
In message [EMAIL PROTECTED], Tony Finch writes: fork() with big data segments that cause swap to be reserved in case of a copy-on-write. The 2GB of swap is never actually used, but you still have to have it. That's a good point. So, we should warn people that asking for memory committments,