From: Hezekiah M. C. <hez...@us...> - 2009-09-24 04:16:32
|
On Wed, Sep 23, 2009 at 10:41 PM, Hazen Babcock <hba...@ma...> wrote: > Hezekiah M. Carty wrote: >> >> On Tue, May 5, 2009 at 4:05 AM, Andrew Ross >> <and...@us...> wrote: >>> >>> On Mon, May 04, 2009 at 06:57:46PM -0700, Alan Irwin wrote: >>>> >>>> On 2009-05-04 13:54-0600 Orion Poplawski wrote: >>>>> >>>>> Something else to think about? >>>>> >>>>> plplot-libs.x86_64: W: shared-lib-calls-exit >>>>> /usr/lib64/libplplotd.so.9.6.2 exit@GLIBC_2.2.5 >>>>> >>>>> plplot-libs.x86_64: W: shared-lib-calls-exit >>>>> /usr/lib64/libqsastime.so.0.0.1 exit@GLIBC_2.2.5 >>>>> >>>>> plplot-libs.x86_64: W: shared-lib-calls-exit >>>>> /usr/lib64/libcsirocsa.so.0.0.1 exit@GLIBC_2.2.5 >>>>> >>>>> plplot-libs.x86_64: W: shared-lib-calls-exit >>>>> /usr/lib64/libcsironn.so.0.0.1 exit@GLIBC_2.2.5 >>>>> >>>>> >>>>> $ rpmlint -I shared-lib-calls-exit >>>>> shared-lib-calls-exit: >>>>> This library package calls exit() or _exit(), probably in a non-fork() >>>>> context. Doing so from a library is strongly discouraged - when a >>>>> library >>>>> function calls exit(), it prevents the calling program from handling >>>>> the >>>>> error, reporting it to the user, closing files properly, and cleaning >>>>> up any >>>>> state that the program has. It is preferred for the library to return >>>>> an >>>>> actual error code and let the calling program decide how to handle the >>>>> situation. >>>> >>>> I agree the "exit" issue is worth thinking about post 5.9.4. Otherwise, >>>> I >>>> believe I have addressed all the issues you raised as of revision 9907. >>>> Thanks for spotting all of those! >>> >>> Debian lintian also complains about this. (See >>> http://lintian.debian.org/full/and...@us...ml ) >>> >>> I've looked at this briefly. There are several uses >>> >>> 1) plparseopts exits if there are invalid command line options or if the >>> -h or -v options are used. This would be "normal" program behaviour, but >>> we could change plparseopts to return an error code in these cases. It >>> would then be up to the program to handle. Would be an API change. >>> >>> 2) plexit (used as default handler by plabort), and throughout the code. >>> Removing plabort would be a significant API change. Removing all >>> occurences >>> of plexit would also be a significant amount of work since C doesn't >>> support >>> excepetions (unlike for example C++, java). >>> >>> 3) Other libraries: nn has a couple of calls to exit via nn_quit for >>> error >>> handling. Could probably be "fixed" with not too much work. qsastime >>> makes >>> quite a few calls to exit for error handling. Again, can be fixed but >>> will >>> be a little bit of work. Also calls in testing routines for nn, csa and >>> qsastime. This is fine - just need to check code is not part of final >>> library. Changes are likely to result in API changes since function >>> return >>> codes will alter. >>> >>> 4) Most drivers call exit or plexit somewhere in their code. Again, may >>> be >>> some work to "fix". >>> >>> This is an unfortunate practice we have got in to. It is now quite well >>> entrenched in the plplot code so will take some work to unravel and will >>> probably result in changes to return codes for a lot of API calls. This >>> will require programs to do a lot more checking. >>> >>> Thoughts? >> >> It has been several months since this was brought up, but I think that >> this is still worth addressing. Having the PLplot exit a program >> completely can be a shock, particularly when using the library >> interactively. I think that making these changes pre-5.10.0 would be >> better than post-5.10.0. Otherwise I expect they would have to wait >> for a 5.11.x development release due to the likelihood of an API >> change. > > If you are using a language that supports exceptions and callbacks from C > you can override the PLplot's default exit() behavior. I attempted that this evening with OCaml after adding plsabort and plsexit support to the language bindings. Unfortunately, I found that plsexit and plsabort do not override the plabort and plexit behavior. Instead, the provided callbacks are called just before the default actions are taken. So plabort always prints out its standard message and plexit always calls plend() and exit(). This is stated in the documentation for plexit and somewhat ambiguous for plabort. I had only read the plsexit and plsabort documentation before binding these functions so this was a bit of a shock to me. Is there a different way to override the plexit and plabort calls? > Thoughts about how we would implement this? Would we have to change every > function in API to return a success or failure code? This seems like a huge > change, the kind of change that would take us from version 5 to version 6. After looking through the code Andrew mentioned in his post, this does look like a very large task. If there is no way currently to fully override plexit and/or plabort, changing plexit/plabort to allow this may be a more acceptable behavioral change without having to jump to version 6.0. Is this an acceptable change, pre-5.10.0? It would not affect the default behavior, but it would change how plexit and plabort act when custom callbacks are defined. Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science |