Robert Watson wrote:I'm not sure that I like that very much. At least the way that it has been explained here so correct me if I misunderstood. I have long lived processes that continuously handle very valuable data and potentially get very large (several GB). I'd like that process to be able to make a rational decision about what happens to its memory contents when an allocation fails rather than having the proverbial rug pulled out from under it. Rug pulling at any point can cost an annual salary or two. Ian -- Ian Freislich _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
| Jeff Chua | 2.6.27rc1 cannot boot more than 8CPUs |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Winkler, Tomas | RE: iwlwifi: fix build bug in "iwlwifi: fix LED stall" |
| Evgeniy Polyakov | Re: [BUG] New Kernel Bugs |
git: | |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Andrew Dickinson | tx queue hashing hot-spots and poor performance (multiq, ixgbe) |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
