#29 Behaviour of ~thread

1.0
closed
nobody
None
2014-03-05
2012-08-20
Christoph
No

The current behaviour of the the vislib thread is closing the handle on windows/detaching on Linux. This has the effect that the thread continues running until the runnable exits. However, there is no possiblity to re-gain control over it.

The STL thread on the other hand does not detach in the dtor, but checks whether the thread was detached and explodes the programme if not. This way, the implementation ensures that one cannot have running threads that cannot be controlled by an object.

Should we change the implementation? I am really not sure...

Discussion

  • SGrottel

    SGrottel - 2012-08-21

    What is the reason for having the Linux dtor only detaching?

    I recommend that in a dtor the thread should not be running anymore!

    I had strange behaviour in MegaMol sometimes which I believe was because of orphaned threads.

    So, can we have to dtor to do a join, if the thread is still running?

    Since we will only provide the opaque thread-id object, we do not have to worry about the user tinkering with low-level functions.

     
  • Christoph

    Christoph - 2012-09-14

    VISlib thread mimics the Windows thread handle, which can be closed while the thread is running. It means that I am not interested anymore in what the thread is doing, but I want it to complete its work.

    Joining the thread in the dtor is a bad idea imho, because it poses a significant danger of producing deadlocks unvoluntarily.

     
    • Guido Reina

      Guido Reina - 2012-10-04

      I am not sure whether the deadlock is so bad actually. You can even find those with a debugger... Rather, could you make an example when this goes wrong at the programmer's expense?

       
  • SGrottel

    SGrottel - 2012-10-04

    How about a flag (member) controling whether or not the dtor waits for the thread to finish. I would set "waiting" as the default behaviour.

    In my opinion such a deadlock is the result of bad code. Thus we should not encurrage the programmers to rely on the OS to "clean their mess up". Instead, if a programmer REALLY knowns that there is a real need to let the thread live longer as its object, then he can "request" this especially.

     
  • SGrottel

    SGrottel - 2014-03-05
    • status: open --> closed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks