Boost logo

Boost :

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]>
>>> wrote:
>>>> 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
>>> here>
>> 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, gregod at, cpdaniel at, john at