[filesystem] truncate() function?
There was a request on the users list for a file truncate() function similar to the POSIX function of the same name. Since Windows provides a function with virtually identical semantics, this seems like a reasonable request. The POSIX spec includes: "If the request would cause the file size to exceed the soft file size limit for the process, the request shall fail and the implementation shall generate the SIGXFSZ signal for the process." I have no knowledge of or experience with POSIX signals, so need advice. Does the POSIX implementation need to do anything to cope with the possibility of a SIGXFSZ signal? If so what? Thanks, --Beman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 14 October 2009, Beman Dawes wrote:
There was a request on the users list for a file truncate() function similar to the POSIX function of the same name. Since Windows provides a function with virtually identical semantics, this seems like a reasonable request.
The POSIX spec includes:
"If the request would cause the file size to exceed the soft file size limit for the process, the request shall fail and the implementation shall generate the SIGXFSZ signal for the process."
I have no knowledge of or experience with POSIX signals, so need advice.
Does the POSIX implementation need to do anything to cope with the possibility of a SIGXFSZ signal? If so what?
I don't think you need to do anything. In POSIX, write() can also generate a SIGXFSZ signal. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkrV6CEACgkQ5vihyNWuA4UvyACdExcODHvL0FqtJ/WU7q2KyY9y 2X8An0jt+QMd29UxxD/NXcNPQtWcVZrG =iLLw -----END PGP SIGNATURE-----
On Wed, Oct 14, 2009 at 9:02 AM, Frank Mori Hess <frank.hess@nist.gov> wrote:
Does the POSIX implementation need to do anything to cope with the possibility of a SIGXFSZ signal? If so what?
I don't think you need to do anything. In POSIX, write() can also generate a SIGXFSZ signal.
Yeah, I would say you don't need to do anything *special*, other than the "normal" error/exception handling. Jon
On Wed, 14 Oct 2009, Beman Dawes wrote:
Does the POSIX implementation need to do anything to cope with the possibility of a SIGXFSZ signal? If so what?
Don't do anything. Signal handlers are global; so it is generally poor form for a library to install one unless explicitely requested. FYI, the linux manpages say http://www.kernel.org/doc/man-pages/online/pages/man7/signal.7.html "" Next the signals not in the POSIX.1-1990 standard but described in SUSv2 and POSIX.1-2001. Signal Value Action Comment -------------------------------------------------------------------- ... SIGXFSZ 25,25,31 Core File size limit exceeded (4.2BSD) Up to and including Linux 2.2, the default behavior for SIGSYS, SIGXCPU, SIGXFSZ, and (on architectures other than SPARC and MIPS) SIGBUS was to terminate the process (without a core dump). (On some other Unix systems the default action for SIGXCPU and SIGXFSZ is to terminate the process without a core dump.) Linux 2.4 conforms to the POSIX.1-2001 requirements for these signals, terminating the process with a core dump. "" On OS X 10.5, the manpages say the default action terminates without a core. - Daniel
"Beman Dawes" <bdawes@acm.org> wrote in message news:4AD5E420.8000003@acm.org...
The POSIX spec includes:
"If the request would cause the file size to exceed the soft file size limit for the process, the request shall fail and the implementation shall generate the SIGXFSZ signal for the process."
This system was designed before return codes where known. I remember having to install/uninstall signal handlers before/after doing a write system call to a socket to prevent the system from killing my process.
On Wed, Oct 14, 2009 at 10:45 AM, Beman Dawes <bdawes@acm.org> wrote:
There was a request on the users list for a file truncate() function similar to the POSIX function of the same name. Since Windows provides a function with virtually identical semantics, this seems like a reasonable request.
The POSIX spec includes:
"If the request would cause the file size to exceed the soft file size limit for the process, the request shall fail and the implementation shall generate the SIGXFSZ signal for the process."
I have no knowledge of or experience with POSIX signals, so need advice.
Does the POSIX implementation need to do anything to cope with the possibility of a SIGXFSZ signal? If so what?
Thanks,
--Beman
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. But I can see this being a more general (and useful) feature - a SIG handler that converts to C++ exceptions. (I've written similar for Windows Structured Exceptions in the past.) Tony
On Wed, Oct 14, 2009 at 8:59 PM, Gottlob Frege <gottlobfrege@gmail.com> 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> Jon
On Wed, Oct 14, 2009 at 10:36 PM, Jonathan Franklin <franklin.jonathan@gmail.com> wrote:
On Wed, Oct 14, 2009 at 8:59 PM, Gottlob Frege <gottlobfrege@gmail.com> 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.
On 10/15/09, OvermindDL1 <overminddl1@gmail.com> wrote:
On Wed, Oct 14, 2009 at 10:36 PM, Jonathan Franklin <franklin.jonathan@gmail.com> wrote:
On Wed, Oct 14, 2009 at 8:59 PM, Gottlob Frege <gottlobfrege@gmail.com> 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. Tony
On Thu, Oct 15, 2009 at 6:48 AM, Gottlob Frege <gottlobfrege@gmail.com> wrote:
On 10/15/09, OvermindDL1 <overminddl1@gmail.com> wrote:
On Wed, Oct 14, 2009 at 10:36 PM, Jonathan Franklin <franklin.jonathan@gmail.com> wrote:
On Wed, Oct 14, 2009 at 8:59 PM, Gottlob Frege <gottlobfrege@gmail.com> 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.
On Thu, Oct 15, 2009 at 9:10 AM, OvermindDL1 <overminddl1@gmail.com> wrote:
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.
I don't think you'll be able to know which writing thread actually generated the signal, and hence the exception. Seems like all writers will end up throwing *after* their write call returns. Throwing after write returns also seems problematic. If the signal doesn't kill the app, then does the write continue, generating additional signals, and for how long? When does write return? This would be your one chance to check the signal state. Jon
"Gottlob Frege" <gottlobfrege@gmail.com> wrote in message news:97ffb310910141959v5f1ac1beqc175652703b80179@mail.gmail.com...
But I can see this being a more general (and useful) feature - a SIG handler that converts to C++ exceptions. (I've written similar for Windows Structured Exceptions in the past.)
On Thu, Oct 15, 2009 at 1:12 PM, Peter Foelsche <peter_foelsche@agilent.com> wrote:
"Gottlob Frege" <gottlobfrege@gmail.com> wrote in message news:97ffb310910141959v5f1ac1beqc175652703b80179@mail.gmail.com...
But I can see this being a more general (and useful) feature - a SIG handler that converts to C++ exceptions. (I've written similar for Windows Structured Exceptions in the past.)
Lots of interesting reading in there - thanks. I think one of the unmentioned conclusions to be made from the discussion is that some signals/OSExceptions are recoverable, some are not. This also ties in with past discussions about whether contract violations should throw or abort() or 'do not pass go, but go straight to some sort of panic-save-exit routine'. Tony
participants (7)
-
Beman Dawes -
dherring＠ll.mit.edu -
Frank Mori Hess -
Gottlob Frege -
Jonathan Franklin -
OvermindDL1 -
Peter Foelsche