Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. pthread_cancel issue

pthread_cancel issue

Scheduled Pinned Locked Moved C / C++ / MFC
helpquestioncareer
4 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • Y Offline
    Y Offline
    ytubis
    wrote on last edited by
    #1

    Hi, I have an issue when using this function, the scenario is like that: thread 1 invokes and creates thread 2 which monitors some data, using pthread_create with PTHREAD_CANCEL_ENABLE and PTHREAD_CANCEL_DEFERRED, then when thread 1 finishes his job it cancels thread 2 using pthread_cancel and everything is working fine, but the problem is that it seems that the threads are dead but still connected to the main projcess. I am usin QNX OS which is a BSD flavor, same as Unix, process view: 37560404 1 ./omadm_client 10r JOIN 5 37560404 2 ./omadm_client 10r CONDVAR 37560404 3 ./omadm_client 10r CONDVAR 37560404 4 ./omadm_client 10r REPLY 37560404 5 ./omadm_client 10r REPLY 37560404 6 ./omadm_client 10r DEAD 37560404 7 ./omadm_client 10r DEAD 37560404 8 ./omadm_client 10r DEAD 37560404 9 ./omadm_client 10r DEAD 37560404 10 ./omadm_client 10r DEAD is it ok? how can I detach them from my main proccess? I do not see the point of uisn pthread_join unless it needs to be invoked for the termination process.. Many thanks, Yossi,

    L 1 Reply Last reply
    0
    • Y ytubis

      Hi, I have an issue when using this function, the scenario is like that: thread 1 invokes and creates thread 2 which monitors some data, using pthread_create with PTHREAD_CANCEL_ENABLE and PTHREAD_CANCEL_DEFERRED, then when thread 1 finishes his job it cancels thread 2 using pthread_cancel and everything is working fine, but the problem is that it seems that the threads are dead but still connected to the main projcess. I am usin QNX OS which is a BSD flavor, same as Unix, process view: 37560404 1 ./omadm_client 10r JOIN 5 37560404 2 ./omadm_client 10r CONDVAR 37560404 3 ./omadm_client 10r CONDVAR 37560404 4 ./omadm_client 10r REPLY 37560404 5 ./omadm_client 10r REPLY 37560404 6 ./omadm_client 10r DEAD 37560404 7 ./omadm_client 10r DEAD 37560404 8 ./omadm_client 10r DEAD 37560404 9 ./omadm_client 10r DEAD 37560404 10 ./omadm_client 10r DEAD is it ok? how can I detach them from my main proccess? I do not see the point of uisn pthread_join unless it needs to be invoked for the termination process.. Many thanks, Yossi,

      L Offline
      L Offline
      Luc Pattyn
      wrote on last edited by
      #2

      It has been a long time since I used QNX, however what follows applies to all kernels and operating systems AFAIK: - cancelling a thread often is unreliable; in general you don't know what state the thread and its data is in when you issue the cancel command, so you could end up with inconsistent data, with locked resources, etc. - the better approach is "cooperative termination", where the thread's code helps in the thread either keeping active or exiting regularly. So what I prefer to do in a monitoring thread typically looks like this (pseudo-code):

      while(!enough) {
      do whatever is needed for monitoring
      wait a while
      }

      and when the caller wants it to terminate, just have it set the global boolean "enough" to true, the monitoring thread will exit (although not immediately, but that most often is OK). :)

      Luc Pattyn [My Articles] Nil Volentibus Arduum

      Y 1 Reply Last reply
      0
      • L Luc Pattyn

        It has been a long time since I used QNX, however what follows applies to all kernels and operating systems AFAIK: - cancelling a thread often is unreliable; in general you don't know what state the thread and its data is in when you issue the cancel command, so you could end up with inconsistent data, with locked resources, etc. - the better approach is "cooperative termination", where the thread's code helps in the thread either keeping active or exiting regularly. So what I prefer to do in a monitoring thread typically looks like this (pseudo-code):

        while(!enough) {
        do whatever is needed for monitoring
        wait a while
        }

        and when the caller wants it to terminate, just have it set the global boolean "enough" to true, the monitoring thread will exit (although not immediately, but that most often is OK). :)

        Luc Pattyn [My Articles] Nil Volentibus Arduum

        Y Offline
        Y Offline
        ytubis
        wrote on last edited by
        #3

        Hi, Thanks for the answer, it is a problem because this thread is monitoring a file which it waits (sleeps) on it till something changes, so if nothing changes we will still sleep on the IO forever, I free the global resources of the thread so this is not my cuncern, but do you know how to detach the thread from the process? Many thanks, Yossi,

        L 1 Reply Last reply
        0
        • Y ytubis

          Hi, Thanks for the answer, it is a problem because this thread is monitoring a file which it waits (sleeps) on it till something changes, so if nothing changes we will still sleep on the IO forever, I free the global resources of the thread so this is not my cuncern, but do you know how to detach the thread from the process? Many thanks, Yossi,

          L Offline
          L Offline
          Luc Pattyn
          wrote on last edited by
          #4

          ytubis wrote:

          do you know how to detach the thread from the process?

          Sorry, I don't recall. I'm sure you could find that easily in the doc though.

          ytubis wrote:

          if nothing changes we will still sleep on the IO forever

          I tend never to do that; when the OS supports it, I prefer giving a reasonable timeout to all system calls, and then implement my own loop around it (possibly with logging and other logistics). :)

          Luc Pattyn [My Articles] Nil Volentibus Arduum

          1 Reply Last reply
          0
          Reply
          • Reply as topic
          Log in to reply
          • Oldest to Newest
          • Newest to Oldest
          • Most Votes


          • Login

          • Don't have an account? Register

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • World
          • Users
          • Groups