If I have one thread blocked on a read on a serial port is there any way
in
software that another thread can force the first thread to unblock
without
having received anything on the serial port. I’ve tried tcinject but it
fails moaning about a inappropriate i/o operation…
What I need to do is just a one off ‘unblock’ or dummy write to the
serial port somehow such that read unblocks and continues thru the code.
This is a one off situation to cover where a remote terminal on one
serial port has died and another RT on another port wants to take over
the comms (i.e. I just remap the file descriptors for the new port).
This seems to work fine if I can just get the original blocked read to
unblock…
Not elegant but you could provide a signal handler for the blockee to
respond gracefully to a signal such as SIGUSR1. Or not gracefully if
it’s safe for it to simply die.
There may be permission issues if the signaler doesn’t have root perms
and wasn’t started by the same usrid as the blockee.
A more involved solution would have the blockee use select(). A proxy
from the monitor would trigger termination code.
Richard
sensicom wrote:
Hi
If I have one thread blocked on a read on a serial port is there any way
in
software that another thread can force the first thread to unblock
without
having received anything on the serial port. I’ve tried tcinject but it
fails moaning about a inappropriate i/o operation…
What I need to do is just a one off ‘unblock’ or dummy write to the
serial port somehow such that read unblocks and continues thru the code.
This is a one off situation to cover where a remote terminal on one
serial port has died and another RT on another port wants to take over
the comms (i.e. I just remap the file descriptors for the new port).
This seems to work fine if I can just get the original blocked read to
unblock…
What I need to do is just a one off ‘unblock’ or dummy write to the
serial port somehow such that read unblocks and continues thru the code.
This is a one off situation to cover where a remote terminal on one
serial port has died and another RT on another port wants to take over
the comms (i.e. I just remap the file descriptors for the new port).
This seems to work fine if I can just get the original blocked read to
unblock…
Any clues???
One option you could use is to pthread_cancel() the blocked thread, have it
clean-up and then have the canceling thread start a new thread to take it’s
place.
chris
\
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll – http://qnx.wox.org/
Try using a qnx_proxy_attach() with a dev_read() in conjunction with a
Creceive().
When data is available for reading, the proxy is triggered. This allows your
process to go off and do other things, not having to be blocked on the read.
If I have one thread blocked on a read on a serial port is there any way
in
software that another thread can force the first thread to unblock
without
having received anything on the serial port. I’ve tried tcinject but it
fails moaning about a inappropriate i/o operation…
What I need to do is just a one off ‘unblock’ or dummy write to the
serial port somehow such that read unblocks and continues thru the code.
This is a one off situation to cover where a remote terminal on one
serial port has died and another RT on another port wants to take over
the comms (i.e. I just remap the file descriptors for the new port).
This seems to work fine if I can just get the original blocked read to
unblock…