Setting "zfs_arc_max" value in FreeBSD 8.
Hello, I am trying to tune ZFS file system by setting "zfs_arc_max" value in FreeBSD 8. In solaris, it is achieved like this = For example, if an application needs 5 GBytes of memory on a system with 36-GBytes of memory, you could set the arc maximum to 30 GBytes, (0x78000 or 32212254720 bytes). Set the zfs:zfs_arc_max parameter in the /etc/system file: set zfs:zfs_arc_max = 0x78000 or set zfs:zfs_arc_max = 32212254720 = But, I couldn't find /etc/system file in FreeBSD. Could some one please guide me to correctly configure "zfs_arc_max" in FreeBSD 8. -- Best Regards, Sherin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Setting "zfs_arc_max" value in FreeBSD 8.
On 01/19/10 10:19, Sherin George wrote: Hello, I am trying to tune ZFS file system by setting "zfs_arc_max" value in FreeBSD 8. In solaris, it is achieved like this = For example, if an application needs 5 GBytes of memory on a system with 36-GBytes of memory, you could set the arc maximum to 30 GBytes, (0x78000 or 32212254720 bytes). Set the zfs:zfs_arc_max parameter in the /etc/system file: set zfs:zfs_arc_max = 0x78000 or set zfs:zfs_arc_max = 32212254720 = But, I couldn't find /etc/system file in FreeBSD. Could some one please guide me to correctly configure "zfs_arc_max" in FreeBSD 8. You should probably start here: http://wiki.freebsd.org/ZFSTuningGuide and more generally, here: http://wiki.freebsd.org/ZFS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Setting "zfs_arc_max" value in FreeBSD 8.
Thanks Ivan :) I found It. add following in /boot/loader.conf === vfs.zfs.arc_max="10244M" === -- Best Regards, Sherin On Tue, Jan 19, 2010 at 3:15 PM, Ivan Voras wrote: > On 01/19/10 10:19, Sherin George wrote: > >> Hello, >> >> I am trying to tune ZFS file system by setting "zfs_arc_max" value in >> FreeBSD 8. >> >> In solaris, it is achieved like this >> >> = >> For example, if an application needs 5 GBytes of memory on a system with >> 36-GBytes of memory, you could set the arc maximum to 30 GBytes, >> (0x78000 or 32212254720 bytes). Set the zfs:zfs_arc_max parameter in >> the >> /etc/system file: >> >> set zfs:zfs_arc_max = 0x78000 >> >> or >> >> set zfs:zfs_arc_max = 32212254720 >> = >> >> But, I couldn't find /etc/system file in FreeBSD. >> >> Could some one please guide me to correctly configure "zfs_arc_max" in >> FreeBSD 8. >> > > You should probably start here: > > http://wiki.freebsd.org/ZFSTuningGuide > > and more generally, here: > > http://wiki.freebsd.org/ZFS > > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
pthread_{mutex,cond} & fifo/starvation/scheduling policy
Hi everyone,
I'm curious to the exact scheduling policy of POSIX threads in relation to
mutexes and conditions. If there are two threads (a & b), both with the
following code:
while (1) {
pthread_mutex_lock(mutex);
...
pthread_mutex_unlock(mutex);
}
What is the scheduling policy of the different thread libraries? Are both
threads getting an equal amount of time? Are there no starvation issues (are
they executed in alternating turns)? (a test program of mine indicates that
libpthread and libthr both have starvation issues, in contrary to Mac OS X 10.6)
Also, I'm interested in the scheduling behaviour in combination with
pthread_cond. Get a signalled thread priority to relock the mutex it is waiting
on, or is the relock operation just a normal lock operation and is handled as
such? (so different kind of starvation issues can occur in the latter case)
I have googled extensively and browsed the libthr sources, but can't find the
specs that I'm looking for. Any help will appreciated.
With regards,
Bernard van Gastel
Re: pthread_{mutex,cond} & fifo/starvation/scheduling policy
Bernard van Gastel writes:
> What is the scheduling policy of the different thread libraries?
Threads are scheduled by the kernel, not by the library. Look at
sys/kern/sched_umtx.c and sys/kern/sched_{4bsd,ule}.c.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Setting "zfs_arc_max" value in FreeBSD 8.
2010/1/19 Ivan Voras > On 01/19/10 10:19, Sherin George wrote: > >> Hello, >> >> I am trying to tune ZFS file system by setting "zfs_arc_max" value in >> FreeBSD 8. >> >> In solaris, it is achieved like this >> >> = >> For example, if an application needs 5 GBytes of memory on a system with >> 36-GBytes of memory, you could set the arc maximum to 30 GBytes, >> (0x78000 or 32212254720 bytes). Set the zfs:zfs_arc_max parameter in >> the >> /etc/system file: >> >> set zfs:zfs_arc_max = 0x78000 >> >> or >> >> set zfs:zfs_arc_max = 32212254720 >> = >> >> But, I couldn't find /etc/system file in FreeBSD. >> >> Could some one please guide me to correctly configure "zfs_arc_max" in >> FreeBSD 8. >> > > You should probably start here: > > http://wiki.freebsd.org/ZFSTuningGuide > > and more generally, here: > > http://wiki.freebsd.org/ZFS > > > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > sysctl vfs.zfs.arc_max= add it to /etc/sysctl.conf to make persistent ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Q:possibility PFIL+mbuf use for packet spawning
I coded all checksum calculations code. All works ok when i just modifying
data of packets(like all T letters to Q letters)
But now i get some strange error:
packet1: TestMessage.
packet2: 2nd message
im using on first packet only next code(data is a pointer to char* from mbuf
containing strings):
TEST[0]='G';
TEST[1]='\0';
int res=m_append(*m,2,TEST);
m_fixhdr(*m);
printf("res cames from m_append:%d \n",res);
printf("new data string is %s \n",data);
iph->ip_len+=2;//modifying IP header length
Then recalculatin IP and TCP cheksums(correctly seems because network doesnt
drop packets)
And server got message:"Test Message.Qnd message" As well server reply with
ACK=25. So seems no new chars were added.
Seems like im overwriting 2nd packet. But why this happening?
Thank you :)
Yours, Qspirit.
PS sorry Max for double mail, forgot to add cc hackers.
2010/1/15 Max Laier
> On Friday 15 January 2010 12:26:06 q q wrote:
> > I'm using pfil as packet filter for packet modifications.
> >
> > Is it possible to spawn new packets to network from pfil using mbuf?
>
> You can call into ip_output with a new mbuf to send a new packet. See for
> example pf_send_tcp in contrib/pf/net/pf.c
>
> > Another question: im using m_append to change packet length and add
> > data(its working, at least server got longer message) but when i
> wireshark
> > clients packets(win machine) i see that i got acknoledge on older length
> > not on new one. Am i missunderstanding something?
>
> Assuming you are talking about tcp packets (otherwise there wouldn't be an
> ack), you have to alter the tcp header, checksums, etc. as well. Just
> adding
> data doesn't work.
>
> Regards,
> --
> Max
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Q:possibility PFIL+mbuf use for packet spawning
Error: line And server got message:"Test Message.Qnd message" should read
as line
And server got message:"Test Message.G\0d message".
Sent you last logs, big Apologises :(
2010/1/19 q q
>
> I coded all checksum calculations code. All works ok when i just modifying
> data of packets(like all T letters to Q letters)
>
> But now i get some strange error:
> packet1: TestMessage.
> packet2: 2nd message
>
> im using on first packet only next code(data is a pointer to char* from
> mbuf containing strings):
>
> TEST[0]='G';
> TEST[1]='\0';
> int res=m_append(*m,2,TEST);
> m_fixhdr(*m);
> printf("res cames from m_append:%d \n",res);
> printf("new data string is %s \n",data);
> iph->ip_len+=2;//modifying IP header length
>
> Then recalculatin IP and TCP cheksums(correctly seems because network
> doesnt drop packets)
>
> And server got message:"Test Message.Qnd message" As well server reply with
> ACK=25. So seems no new chars were added.
> Seems like im overwriting 2nd packet. But why this happening?
>
> Thank you :)
>
> Yours, Qspirit.
>
> PS sorry Max for double mail, forgot to add cc hackers.
>
> 2010/1/15 Max Laier
>
>> On Friday 15 January 2010 12:26:06 q q wrote:
>>
>> > I'm using pfil as packet filter for packet modifications.
>> >
>> > Is it possible to spawn new packets to network from pfil using mbuf?
>>
>> You can call into ip_output with a new mbuf to send a new packet. See for
>> example pf_send_tcp in contrib/pf/net/pf.c
>>
>> > Another question: im using m_append to change packet length and add
>> > data(its working, at least server got longer message) but when i
>> wireshark
>> > clients packets(win machine) i see that i got acknoledge on older
>> length
>> > not on new one. Am i missunderstanding something?
>>
>> Assuming you are talking about tcp packets (otherwise there wouldn't be an
>> ack), you have to alter the tcp header, checksums, etc. as well. Just
>> adding
>> data doesn't work.
>>
>> Regards,
>> --
>> Max
>>
>
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Setting "zfs_arc_max" value in FreeBSD 8.
On 1/19/2010 5:16 AM, Sherin George wrote: > Thanks Ivan :) > > I found It. add following in /boot/loader.conf > > === > vfs.zfs.arc_max="10244M" > === > > -- > Best Regards, > Sherin > > On Tue, Jan 19, 2010 at 3:15 PM, Ivan Voras wrote: > >> On 01/19/10 10:19, Sherin George wrote: >> >>> Hello, >>> >>> I am trying to tune ZFS file system by setting "zfs_arc_max" value in >>> FreeBSD 8. >>> >>> In solaris, it is achieved like this >>> >>> = >>> For example, if an application needs 5 GBytes of memory on a system with >>> 36-GBytes of memory, you could set the arc maximum to 30 GBytes, >>> (0x78000 or 32212254720 bytes). Set the zfs:zfs_arc_max parameter in >>> the >>> /etc/system file: >>> >>> set zfs:zfs_arc_max = 0x78000 >>> >>> or >>> >>> set zfs:zfs_arc_max = 32212254720 >>> = >>> >>> But, I couldn't find /etc/system file in FreeBSD. >>> >>> Could some one please guide me to correctly configure "zfs_arc_max" in >>> FreeBSD 8. >>> >> >> You should probably start here: >> >> http://wiki.freebsd.org/ZFSTuningGuide >> >> and more generally, here: >> >> http://wiki.freebsd.org/ZFS >> I just thought I would give a shout at this for stable/7 as of last week. I am not sure if this is just me but I had tried to adjust zfs_arc_max and found out that it was unadjusted to my value after the system came back up. Anyone know if it is adjustable on a system with 1024MB of ram ? Is this just being auto calculated by some other value ? -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: pthread_{mutex,cond} & fifo/starvation/scheduling policy
In the last episode (Jan 19), Bernard van Gastel said:
> I'm curious to the exact scheduling policy of POSIX threads in relation to
> mutexes and conditions. If there are two threads (a & b), both with the
> following code:
>
> while (1) {
> pthread_mutex_lock(mutex);
> ...
> pthread_mutex_unlock(mutex);
> }
>
> What is the scheduling policy of the different thread libraries? Are both
> threads getting an equal amount of time? Are there no starvation issues
> (are they executed in alternating turns)? (a test program of mine
> indicates that libpthread and libthr both have starvation issues, in
> contrary to Mac OS X 10.6)
There's no guarantee of fairness when dealing with mutexes afaik. My guess
is that if thread "a" unlocks the mutex and still has time left in its
quantum, it'll be able to grab it again without even going to the kernel.
>From the POSIX docs on mutexes:
http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_lock.html#tag_16_439_08
"Mutex objects are intended to serve as a low-level primitive from which
other thread synchronization functions can be built. As such, the
implementation of mutexes should be as efficient as possible, and this
has ramifications on the features available at the interface.
The mutex functions and the particular default settings of the mutex
attributes have been motivated by the desire to not preclude fast,
inlined implementations of mutex locking and unlocking."
The idea being that mutexes should be held for as little time as possible.
Is there a way to write your code so that most of the CPU-consuming activity
is done outside of the mutex? Perhaps use a job queue of some sort, and
only lock the mutex when pushing/popping elements. Then worker processes
can run without holding the mutex, and will be fairly scheduled by the
kernel.
--
Dan Nelson
dnel...@allantgroup.com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: limits for run away Firefox ?
On Mon, Jan 18, 2010 at 12:25:43PM -0800, Doug Barton wrote: > On 01/18/10 11:29, Oliver Fromme wrote: > > Doug Barton wrote: > > > On 01/17/10 17:07, Julian H. Stacey wrote: > > > > Hi hackers > > > > I'm tired of my X server occasionaly freezing, swap thrasing, & > > firefox dumps: > > > > 4,346,937,344 ~/firefox-bin.core > > > > so as a temporary cludge I ran > > > > touch ~/firefox-bin.core ; chmod 000 ~/firefox-bin.core > > > > > > Sorry I don't have a solution to your actual problem, but a better way > > > to deal with this is to do: ln -s /dev/null ~/firefox-bin.core > > > > I think not generating a core dump at all is better than > > writing 4 GB to /dev/null. > > A) The method I proposed is useful for other things too, and as you > pointed out it can sometimes be difficult to track down all the ways a > given thing is started. What about just adding the limit command to the /usr/local/bin/firefox script? That would guarantee any instantiation of firefox wouldn't dump core. > B) If we're going to be snarky, it would be far better if it didn't need > to dump core in the first place. :) I don't think that Oliver was at all snarky. He was merely suggesting a solution which would prevent the core file from being generated at all; the OP was tired of the extra time spent and Oliver's suggestion would certainly reduce this time. The symlink seems to hackish to me, although I've had to use it often in other situations. And in some cases the culprit would unlink(2) it first, so I've had to "chflags noschg" it, which works better than "chmod 000" (if the FS supports it). But I agree that it would be nice to prevent ffox from segfaulting; unfortunately this is one of those apps which segfaults a lot (for me at least). =) Cheers, -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: limits for run away Firefox ?
"Rick C. Petty" wrote: > On Mon, Jan 18, 2010 at 12:25:43PM -0800, Doug Barton wrote: > > On 01/18/10 11:29, Oliver Fromme wrote: > > > Doug Barton wrote: > > > > On 01/17/10 17:07, Julian H. Stacey wrote: > > > > > Hi hackers > > > > > I'm tired of my X server occasionaly freezing, swap thrasing, & > > > > > firefox dumps: 4,346,937,344 ~/firefox-bin.core > > > > > so as a temporary cludge I ran > > > > > touch ~/firefox-bin.core ; chmod 000 ~/firefox-bin.core > > > > > > > > Sorry I don't have a solution to your actual problem, but a > > > > better way to deal with this is to do: ln -s /dev/null > > > > ~/firefox-bin.core > > > > > > I think not generating a core dump at all is better than > > > writing 4 GB to /dev/null. > > > > A) The method I proposed is useful for other things too, and as you > > pointed out it can sometimes be difficult to track down all the ways a > > given thing is started. > > What about just adding the limit command to the /usr/local/bin/firefox > script? That would guarantee any instantiation of firefox wouldn't dump > core. Until the next update ... > > B) If we're going to be snarky, it would be far better if it didn't > > need to dump core in the first place. :) > > I don't think that Oliver was at all snarky. He was merely suggesting a > solution which would prevent the core file from being generated at all; > the OP was tired of the extra time spent and Oliver's suggestion would > certainly reduce this time. > > The symlink seems to hackish to me, although I've had to use it often in > other situations. And in some cases the culprit would unlink(2) it > first, so I've had to "chflags noschg" it, which works better than > "chmod 000" (if the FS supports it). > > But I agree that it would be nice to prevent ffox from segfaulting; > unfortunately this is one of those apps which segfaults a lot (for me at > least). =) I get a lot less segfaults since I disabled ogg support (which never worked for me anyway): about:config -> media.ogg.enabled = false Fabian signature.asc Description: PGP signature
Re: limits for run away Firefox ?
Rick C. Petty wrote: > On Mon, Jan 18, 2010 at 12:25:43PM -0800, Doug Barton wrote: > > On 01/18/10 11:29, Oliver Fromme wrote: > > > Doug Barton wrote: > > > > On 01/17/10 17:07, Julian H. Stacey wrote: > > > > > Hi hackers > > > > > I'm tired of my X server occasionaly freezing, swap thrasing, & > > > > > firefox dumps: > > > > > 4,346,937,344 ~/firefox-bin.core > > > > > so as a temporary cludge I ran > > > > > touch ~/firefox-bin.core ; chmod 000 ~/firefox-bin.core > > > > > > > > Sorry I don't have a solution to your actual problem, but a better way > > > > to deal with this is to do: ln -s /dev/null ~/firefox-bin.core > > > > > > I think not generating a core dump at all is better than > > > writing 4 GB to /dev/null. > > > > A) The method I proposed is useful for other things too, and as you > > pointed out it can sometimes be difficult to track down all the ways a > > given thing is started. > > What about just adding the limit command to the /usr/local/bin/firefox > script? That would guarantee any instantiation of firefox wouldn't dump > core. Many users probably don't want any core dumps at all, so disabling them completely would be the best and easiest solution for them. This can be done globally (either with the sysctl or via /etc/login.conf) or per-user via ~/.login_conf. Then you don't have to track down the ways a given thing is started. > > B) If we're going to be snarky, it would be far better if it didn't need > > to dump core in the first place. :) > > I don't think that Oliver was at all snarky. The word "snarky" isn't even in my dictionary, so I can only guess what it means. Anyway, my suggestion was meant to be completely serious, without any irony or other undertone. I'm not a native English speaker, so maybe my words expressed a meaning that wasn't intended. In that case please allow me to apologize. > But I agree that it would be nice to prevent ffox from segfaulting; Definitely. I agree, too. However, that's a lot more difficult than preventing core dumps being written. > unfortunately this is one of those apps which segfaults a lot (for me at > least). =) One of the reasons why I prefer Opera. :) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C++ is over-complicated nonsense. And Bjorn Shoestrap's book a danger to public health. I tried reading it once, I was in recovery for months." -- Cliff Sarginson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: limits for run away Firefox ? [SEC=UNCLASSIFIED]
0n Tue, Jan 19, 2010 at 10:51:02PM +0100, Fabian Keil wrote: >"Rick C. Petty" wrote: > >> On Mon, Jan 18, 2010 at 12:25:43PM -0800, Doug Barton wrote: >> > On 01/18/10 11:29, Oliver Fromme wrote: >> > > Doug Barton wrote: >> > > > On 01/17/10 17:07, Julian H. Stacey wrote: >> > > > > Hi hackers >> > > > > I'm tired of my X server occasionaly freezing, swap thrasing, & >> > > > > firefox dumps: 4,346,937,344 ~/firefox-bin.core >> > > > > so as a temporary cludge I ran >> > > > > touch ~/firefox-bin.core ; chmod 000 ~/firefox-bin.core >> > > > >> > > > Sorry I don't have a solution to your actual problem, but a >> > > > better way to deal with this is to do: ln -s /dev/null >> > > > ~/firefox-bin.core how about using: #chflags schg /firefox-bin.core ? -Alex IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: limits for run away Firefox ?
No offense was implied, thus the smiley. ;) Doug Sent from my iPhone On Jan 19, 2010, at 1:54 PM, Oliver Fromme wrote: Rick C. Petty wrote: On Mon, Jan 18, 2010 at 12:25:43PM -0800, Doug Barton wrote: On 01/18/10 11:29, Oliver Fromme wrote: Doug Barton wrote: On 01/17/10 17:07, Julian H. Stacey wrote: Hi hackers I'm tired of my X server occasionaly freezing, swap thrasing, & firefox dumps: 4,346,937,344 ~/firefox-bin.core so as a temporary cludge I ran touch ~/firefox-bin.core ; chmod 000 ~/firefox-bin.core Sorry I don't have a solution to your actual problem, but a better way to deal with this is to do: ln -s /dev/null ~/firefox-bin.core I think not generating a core dump at all is better than writing 4 GB to /dev/null. A) The method I proposed is useful for other things too, and as you pointed out it can sometimes be difficult to track down all the ways a given thing is started. What about just adding the limit command to the /usr/local/bin/ firefox script? That would guarantee any instantiation of firefox wouldn't dump core. Many users probably don't want any core dumps at all, so disabling them completely would be the best and easiest solution for them. This can be done globally (either with the sysctl or via /etc/login.conf) or per-user via ~/.login_conf. Then you don't have to track down the ways a given thing is started. B) If we're going to be snarky, it would be far better if it didn't need to dump core in the first place. :) I don't think that Oliver was at all snarky. The word "snarky" isn't even in my dictionary, so I can only guess what it means. Anyway, my suggestion was meant to be completely serious, without any irony or other undertone. I'm not a native English speaker, so maybe my words expressed a meaning that wasn't intended. In that case please allow me to apologize. But I agree that it would be nice to prevent ffox from segfaulting; Definitely. I agree, too. However, that's a lot more difficult than preventing core dumps being written. unfortunately this is one of those apps which segfaults a lot (for me at least). =) One of the reasons why I prefer Opera. :) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfueh rung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Ge bhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C++ is over-complicated nonsense. And Bjorn Shoestrap's book a danger to public health. I tried reading it once, I was in recovery for months." -- Cliff Sarginson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
回复： about libstdc++ ,change the d efaule allocator
Thanks 发件人： Xin LI 收件人： Jiandong Lu 抄 送： freebsd-hackers@freebsd.org 发送日期： 2010/1/15 (周五) 2:54:42 上午 主 题： Re: about libstdc++ ,change the defaule allocator 2010/1/13 Jiandong Lu : > hello,everyone. > 聽 聽 I get the current source code from svn,and successfully build world. > 聽 聽 c++'s standard library is from gnu. This library privodes many allocators: > bitmap_allocator_base > malloc_allocator_base > mt_allocator_base > new_allocator_base > pool_allocator_base > I want to know how to set a default allocator,and how to change it. > > I have read the Makefile: > /usr/src/gnu/lib/libstdc++/Makefile I have no idea why you will think the allocator is being changed here... The standard and portable way to override the allocator is at the point you instance C++ templates by specifing Allocator parameter. If, however, you want to globally change the default allocator without touching all your source files, the only way is to make modification on c++allocator.h, which is, in my opinion, never permitted by the standard and banned by god. Cheers, -- Xin LI http://www.delphij.net ___ 好玩贺卡等你发，邮箱贺卡全新上线！ http://card.mail.cn.yahoo.com/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
