Results 1 to 2 of 2

Thread: QThread and signals (linux/UNIX signals not Qt Signals)

  1. #1
    Join Date
    Jun 2007
    Posts
    56
    Thanks
    6
    Thanked 1 Time in 1 Post
    Qt products
    Qt4 Qt/Embedded
    Platforms
    Unix/X11

    Default QThread and signals (linux/UNIX signals not Qt Signals)

    I have a Qthread that is started using start() from the main GUI and has code in the run() method that sleeps on a message queue looking for a particular message. If the user exits the application, I call the thread's stop() method which toggles a "run" variable and returns. The main GUI then calls the thread's wait() method which waits forever.

    The reason the main GUI waits forever is that the thread is sleeping in msgrcv() and there is nothing in my code presently to cause it to wake up. The man page says that it will only wake up if it sees the message that it is looking for, has the message queue removed from underneath it, or receives a signal that it can't ignore.

    The first condition may or may not happen, but its unreliable at best for waking up the thread.

    The second is not feasible as it would wreak havoc on the rest of my application.

    The third condition is most likely the route I need to take. So how does one send a linux signal like SIGHUP or SIGKILL to a QThread from the main GUI?

    Thanks,

    -Mic

  2. #2
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,360
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: QThread and signals (linux/UNIX signals not Qt Signals)

    I suggest that you modify the msgrcv call so that it is non-blocking - you can obtain that by passing IPC_NOWAIT as one of the flags. This way the call will return immediately even if no message is waiting in the queue. It will then set errno to ENOMSG. Then you'll be able to repeat the call after some time to see if something entered the queue in the meantime.

    If you insist on using signals, I'd suggest sending SIGALRM instead... You have to mask signals you don't want to intercept in each thread (man sigprocmask is your friend). Then you can hope the appropriate thread receives it.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Digia, Qt and their respective logos are trademarks of Digia Plc in Finland and/or other countries worldwide.