I have encountered a problem with usbd_disconnect. I am not sure why the
problem exists. Here is a description of the problem:
My program has a main thread that connects to the usb stack through a usb
library call (usbd_connect). This library is linked in through libusbdi.a.
The usb library creates thread 2 to talk to the host controller driver.
Later on, my program loads a shared object that also connects to the host
controller. This shared object links to libusbdi.so. When an object from
the shared object is created, the libusbdi.so is loaded. The newly created
object connects to the usb stack and starts thread 3.
Some time later, my program does not need the object any longer. In the
destructor for my object, there is a call to usbd_disconnect. This is
supposed to detach from the usb stack and remove thread 3. The problem
occurs when the thread is killed. A SIGSEGV occurs right after an unblock
from the host controller driver. My entire program crashes and terminates.
Within usbd_disconnect, there is a call to pthread_kill that removes this
thread. I changed the pthread_kill call to pthread_cancel and the problem
goes away. Can anyone explain why this is happening? Should pthread_cancel
be used instead of pthread_kill?
Please help.
Rex Lam
I have just read the following post from qdn.public.qnxrtp.os. It sounds
like pthread_cancel should be used instead of pthread_kill. Can this change
be made to usbd_disconnect? It would allow me to unload my shared object
when it is no longer required. I cannot trap on SIGKILL so I cannot handle
the signal differently. Please respond.
-------------------------------- Pasted from
qdn.public.qnxrtp.os --------------------------------
“Alain Magloire” <alain@qnx.com> wrote in message
news:9hv9tj$5nd$1@nntp.qnx.com…
David Gibbs <> dagibbs@qnx.com> > wrote:
: Xuedong Chen <> Xuedong.Chen@igt.com> > wrote:
:> When I use this call to kill one thread in my process, it seems that it
:> killed all threads in the process. Does anyone know why? Can we just
kill a
:> thread (by specify its tid) without affecting others?
: I’d suggest pthread_cancel() – it gives the cleanest handling of this.
: pthread_abort() is much more severe. What I expect is happening with
: pthread_kill() is the signal is getting delivered, not being handled,
: and that thread has the PTHREAD_MULTISIG_ALLOW flag set (Posix default)
: which means if an uncaught/unhandled/not-ignored signal terminates a
: thread, the whole process will be terminated.
BTW pthread_cancel() will cancel at “cancellation point”, so if
you are sitting on a tight loop it may not do what you thing.
Cancelling a thread is never a good idea unless you can “control”
when it is cancel. For example cancelling
a thread while it is in the photon lib, is simply asking for trouble.
Photon is not cancel-safe.
–
alain
-------------------------------- End paste from
qdn.public.qnxrtp.os --------------------------------
“Rex Lam” <Rex.Lam@igt.com> wrote in message
news:9kngju$7a1$1@inn.qnx.com…
I have encountered a problem with usbd_disconnect. I am not sure why the
problem exists. Here is a description of the problem:
My program has a main thread that connects to the usb stack through a usb
library call (usbd_connect). This library is linked in through
libusbdi.a.
The usb library creates thread 2 to talk to the host controller driver.
Later on, my program loads a shared object that also connects to the host
controller. This shared object links to libusbdi.so. When an object from
the shared object is created, the libusbdi.so is loaded. The newly
created
object connects to the usb stack and starts thread 3.
Some time later, my program does not need the object any longer. In the
destructor for my object, there is a call to usbd_disconnect. This is
supposed to detach from the usb stack and remove thread 3. The problem
occurs when the thread is killed. A SIGSEGV occurs right after an unblock
from the host controller driver. My entire program crashes and
terminates.
Within usbd_disconnect, there is a call to pthread_kill that removes this
thread. I changed the pthread_kill call to pthread_cancel and the problem
goes away. Can anyone explain why this is happening? Should
pthread_cancel
be used instead of pthread_kill?
Please help.
Rex Lam
Rex Lam <Rex.Lam@igt.com> wrote:
: I have just read the following post from qdn.public.qnxrtp.os. It sounds
: like pthread_cancel should be used instead of pthread_kill. Can this change
: be made to usbd_disconnect? It would allow me to unload my shared object
: when it is no longer required. I cannot trap on SIGKILL so I cannot handle
: the signal differently. Please respond.
Indeed, dropping SIGKILL on the client processing thread was overkill,
and this was changed to (indeed) pthread_cancel() back in March, and a
new DDK made available to QA for release … they will have to comment
on if this is / why this is not available for update yet …
I am using an older library because I have not changed to 6.1 yet. The new
ddk probably has this changed to pthread_cancel already. Thanks for the
reply. I’m glad to hear that it has already been taken care of.
Rex
“John Garvey” <jgarvey@qnx.com> wrote in message
news:9kpa5s$hmn$1@nntp.qnx.com…
Rex Lam <> Rex.Lam@igt.com> > wrote:
: I have just read the following post from qdn.public.qnxrtp.os. It
sounds
: like pthread_cancel should be used instead of pthread_kill. Can this
change
: be made to usbd_disconnect? It would allow me to unload my shared
object
: when it is no longer required. I cannot trap on SIGKILL so I cannot
handle
: the signal differently. Please respond.
Indeed, dropping SIGKILL on the client processing thread was overkill,
and this was changed to (indeed) pthread_cancel() back in March, and a
new DDK made available to QA for release … they will have to comment
on if this is / why this is not available for update yet …