readcond hangs process

I have some code I’m debugging, where I am talking to a device over a standard com port, and every once in a while the process hangs and stops receiving pulses and other messages. I did some searches to see if anyone else has had this issue, and it didn’t turn up much.

When I catch it with the debugger, it says it is stuck in a MsgSend() call after the readcond(), and the debugger also claims that is has just received a SIGINT signal. That seems odd to me since I’m not doing any interrupt handling myself, unless I am inheriting that from the devc-ser8250 process.

At this point in the code, I am attempting to open the serial device, and flush the buffer before I start taking real data from it.

other vitals:
QNX6.3 SP1

the com port code is below:

//Open COM port
char * temp = new char[80];
sprintf(temp, “/dev/ser%d”, port);
mComPort = open(temp, O_RDWR);
if (mComPort == -1)
fprintf(stderr, “Unable to open COM%d port\n”, port);
// Configure the serial port. The serial port is configured such
// that the baud rate is 38400 with no parity checking, 8 bit data,
// and one stop bit.

  struct termios termio;
  if (tcgetattr(mComPort, &termio))
     fprintf(stderr, "Cannot configure COM%d port\n", port);

  cfsetispeed(&termio, B38400);
  cfsetospeed(&termio, B38400);
  termio.c_iflag &= ~(ICRNL|INLCR);
  termio.c_iflag |= IGNPAR;
  termio.c_oflag &= ~(OPOST);
  termio.c_cflag &= ~(CSIZE|PARENB);
  termio.c_cflag |= CREAD|CS8|CLOCAL;
  termio.c_cflag &= ~(IHFLOW|OHFLOW);

  tcsetattr(mComPort, TCSANOW, &termio);

  //initialize pulse event to occur when data is received on the serial port

  tcflush(mComPort, TCIOFLUSH);
  mSerialFlags = ionotify(mComPort,_NOTIFY_ACTION_POLLARM,
  while (mSerialFlags & _NOTIFY_COND_INPUT)
     while (readcond(mComPort, temp, 80,1,0,10) > 0)
     mSerialFlags = ionotify(mComPort, _NOTIFY_ACTION_POLLARM,


I’m not sure I understand what you are doing inside the two while loops, why create a pulse if you are never going to receive it? Unless some code is missing from you example.

SIGINT has nothing to do with interrupt, it’s more like the program received a CTRL-C.

Well the pulse is used later after the the port has been flushed to receive data normally.

Ahhh… I bet I know what’s going on then with the SIGINT then, that is probably the debugger stopping the process momentarily.

Is there a better solution for draining the com port before we start receiving data normally?

how about tcflush()

tcflush inside the while loop did the job.