| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
On Jul 11, 2008, at 11:50 PM, Alan Hawrylyshen wrote:
On Jul 11, 2008, at 15:25 , Byron Campen wrote:Ok, I have committed the fix, plus some other fixes. Please take the code on head for a spin and see if it handles your testing.Best regards, Byron CampenByron, THanks for that.Seems reasonable except for the catch(std::bad_alloc&) ... I'm not sure it's good MoJo to catch that. Given our amazing reliance on the heap, a failure to allocate is a serious problem. I'm more tempted to subclass the allocator and create 'transport buffers' as a type that we can define an allocator for. Then we can put a limit on the amount of memory in play for transport buffers WITHOUT jepordizing the operation of the rest of the stack. I realize this is something of a change, but it is far safer than implementing a catch of bad_alloc when std::operator new(size_t) the the thrower....
Sure, but what is there is better than nothing; we even free up a good chunk of memory when this code gets hit. We can refine this later. I just want to have something I can backport to 1.3 today.
Best regards, Byron Campen
Attachment:
smime.p7s
Description: S/MIME cryptographic signature