Subject: Re: [boost] [filesystem] truncate() function?
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2009-10-15 11:10:49
On Thu, Oct 15, 2009 at 6:48 AM, Gottlob Frege <gottlobfrege_at_[hidden]> wrote:
> On 10/15/09, OvermindDL1 <overminddl1_at_[hidden]> wrote:
>> On Wed, Oct 14, 2009 at 10:36 PM, Jonathan Franklin
>> <franklin.jonathan_at_[hidden]> wrote:
>>> On Wed, Oct 14, 2009 at 8:59 PM, Gottlob Frege <gottlobfrege_at_[hidden]>
>>>> It may be beyond the scope of Boost.Filesystem, but I'd really prefer
>>>> C++ exceptions to be thrown instead of SIG faults. Â Particularly if
>>>> I'm trying to write x-platform code, which might very well be the
>>>> reason I'm using Boost.Filesystem instead of direct OS calls in the
>>>> first place.
>>> I'm pretty sure that the C and C++ lib calls that write to a file will
>>> result in your app being terminated as a result of the signal in
>>> question when the file being written exceeds the max size.
>>> It's been a *long* time since I've written any posix signal handlers,
>>> but I think you're going to run into control flow problems if you try
>>> to convert this signal to a c++ exception. <cue expert commentary
>> Actually you could probably just set a global volatile boolean, and
>> return from the signal handler as normal. Â Then test for that boolean
>> in the wrapper code, if true then set to false then throw the
>> exception, else return.
> Unfortunately, that is not threadsafe. But I do think it is doable.
> Just probably beyond Boost.Filesystem. Maybe a separate library.
Spinlock, just make all accesses atomic.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk