home *** CD-ROM | disk | FTP | other *** search
/ Game Programming - All in One (3rd Edition) / game_prog_all_in_one_3rd_ed.iso / pthread / docs / BUGS < prev    next >
Encoding:
Text File  |  2003-09-12  |  4.4 KB  |  106 lines
  1. ----------
  2. Known bugs
  3. ----------
  4.  
  5. 1. Not strictly a bug, more of a gotcha.
  6.  
  7.    Under MS VC++ (only tested with version 6.0), a term_func
  8.    set via the standard C++ set_terminate() function causes the
  9.    application to abort.
  10.  
  11.    Notes from the MSVC++ manual:
  12.          1) A term_func() should call exit(), otherwise
  13.             abort() will be called on return to the caller.
  14.             A call to abort() raises SIGABRT and the default signal handler
  15.             for all signals terminates the calling program with
  16.             exit code 3.
  17.          2) A term_func() must not throw an exception. Therefore
  18.             term_func() should not call pthread_exit(), which
  19.             works by throwing an exception (pthreadVCE or pthreadVSE)
  20.             or by calling longjmp (pthreadVC).
  21.  
  22.    Workaround: avoid using pthread_exit() in C++ applications. Exit
  23.    threads by dropping through the end of the thread routine.
  24.  
  25. 2. Cancellation problems in optimised code
  26.    - Milan Gardian
  27.  
  28.    Workaround [rpj - 2 Feb 2002]
  29.    -----------------------------
  30.    The problem disappears when /Ob0 is used, i.e. /O2 /Ob0 works OK,
  31.    but if you want to use inlining optimisation you can be much more
  32.    specific about where it's switched off and on by using a pragma.
  33.  
  34.    So the inlining optimisation is interfering with the way that cleanup
  35.    handlers are run. It appears to relate to auto-inlining of class methods
  36.    since this is the only auto inlining that is performed at /O1 optimisation
  37.    (functions with the "inline" qualifier are also inlined, but the problem
  38.    doesn't appear to involve any such functions in the library or testsuite).
  39.  
  40.    In order to confirm the inlining culprit, the following use of pragmas
  41.    eliminate the problem but I don't know how to make it transparent, putting
  42.    it in, say, pthread.h where pthread_cleanup_push defined as a macro.
  43.  
  44.    #pragma inline_depth(0)
  45.      pthread_cleanup_push(handlerFunc, (void *) &arg);
  46.  
  47.         /* ... */
  48.  
  49.      pthread_cleanup_pop(0);
  50.    #pragma inline_depth()
  51.  
  52.    Note the empty () pragma value after the pop macro. This resets depth to the
  53.    default. Or you can specify a non-zero depth here.
  54.  
  55.    The pragma is also needed (and now used) within the library itself wherever
  56.    cleanup handlers are used (condvar.c and rwlock.c).
  57.  
  58.    Use of these pragmas allows compiler optimisations /O1 and /O2 to be
  59.    used for either or both the library and applications.
  60.  
  61.    Experimenting further, I found that wrapping the actual cleanup handler
  62.    function with #pragma auto_inline(off|on) does NOT work.
  63.  
  64.    MSVC6.0 doesn't appear to support the C99 standard's _Pragma directive,
  65.    however, later versions may. This form is embeddable inside #define
  66.    macros, which would be ideal because it would mean that it could be added
  67.    to the push/pop macro definitions in pthread.h and hidden from the
  68.    application programmer.
  69.  
  70.    [/rpj]
  71.  
  72.    Original problem description
  73.    ----------------------------
  74.  
  75.    The cancellation (actually, cleanup-after-cancel) tests fail when using VC
  76.    (professional) optimisation switches (/O1 or /O2) in pthreads library. I
  77.    have not investigated which concrete optimisation technique causes this
  78.    problem (/Og, /Oi, /Ot, /Oy, /Ob1, /Gs, /Gf, /Gy, etc.), but here is a
  79.    summary of builds and corresponding failures:
  80.  
  81.      * pthreads VSE (optimised tests): OK
  82.      * pthreads VCE (optimised tests): Failed "cleanup1" test (runtime)
  83.  
  84.      * pthreads VSE (DLL in CRT, optimised tests): OK
  85.      * pthreads VCE (DLL in CRT, optimised tests): Failed "cleanup1" test
  86.    (runtime)
  87.  
  88.    Please note that while in VSE version of the pthreads library the
  89.    optimisation does not really have any impact on the tests (they pass OK), in
  90.    VCE version addition of optimisation (/O2 in this case) causes the tests to
  91.    fail uniformly - either in "cleanup0" or "cleanup1" test cases.
  92.  
  93.    Please note that all the tests above use default pthreads DLL (no
  94.    optimisations, linked with either static or DLL CRT, based on test type).
  95.    Therefore the problem lies not within the pthreads DLL but within the
  96.    compiled client code (the application using pthreads -> involvement of
  97.    "pthread.h").
  98.  
  99.    I think the message of this section is that usage of VCE version of pthreads
  100.    in applications relying on cancellation/cleanup AND using optimisations for
  101.    creation of production code is highly unreliable for the current version of
  102.    the pthreads library.
  103.  
  104.  
  105.  
  106.