Unix Programming - permanent callback call when using XtAddAppInput

Author

permanent callback call when using XtAddAppInput

Steffen Christgau

2005-09-29, 7:52 am

Hello folks,

I hope that's the right place for the following problem.

I'm writing a device driver, which handles a special timing hardware. A
daemon watches the device file, logs all events to a file and a named
pipe. Finally a X application (using Motif) should display the incoming
timing signals from the named pipe on the GUI. Therefor, I use the
XtAppAddInput function in the following manner:

void TimingEventCallBack(XtPointer UserData, int* Source,
XtInputId* Input)
{
/* read out the timing signal data [...] */

return;
}

int OpenTimingPipe(void)
{
RoTimingPipe = open(RO_PKG_PIPE_LPATH RO_PKG_CLNT_TMG_PIPE,
O_RDONLY | O_NONBLOCK);

if (RoTimingPipe == -1)
return E_RO_PIPE_OPEN;

RoTimingPipeStream = fdopen(RoTimingPipe, "r");
if (!RoTimingPipeStream)
return E_RO_PIPE_STREAM_OPEN;

return E_RO_NOERROR;
}

int InitTimingConnection(void)
{
if (OpenTimingPipe() == E_RO_NOERROR) {
RoPipeInput = XtAppAddInput(Application, RoTimingPipe,
(XtPointer) XtInputReadMask,
TimingEventCallBack, NULL);
return 1;
}
return 0;
}

The problem is, that the callback function (TimingEventCallBack) is
called permanently as soon some data has been available on the pipe,
although the pipe was emptied afterwards. Due to this the process claims
approx. 100% of the CPU. Has anyone an idea what's the reason - and
maybe a solution - for this unpleasant effect ?

I created the pipe for testing via command line using "mkfifo" and wrote
something on it with "cat exmpdata > mypipe" or "echo." Somewhere I read
about a similar effect when using disk files as input source for
XtAddAppInput. Is it this the answer? Or are there any flags, which may
help?

regards

Steffen

P.S. I'm using SuSE Linux 9.3 with kernel 2.6.11.4-21.9.

Chuck Dillon

2005-09-29, 6:00 pm

Steffen Christgau wrote:

> RoTimingPipe = open(RO_PKG_PIPE_LPATH RO_PKG_CLNT_TMG_PIPE,
> O_RDONLY | O_NONBLOCK);
>
> The problem is, that the callback function (TimingEventCallBack) is
> called permanently as soon some data has been available on the pipe,
> although the pipe was emptied afterwards. Due to this the process claims
> approx. 100% of the CPU. Has anyone an idea what's the reason - and
> maybe a solution - for this unpleasant effect ?

I believe your problem is you've opened it as non-blocking.
XtAppAddInput on *nix calls select() which tells you if your process
would block if you read from a descriptor. In non-blocking mode that's
always true.

BTW, the comp.windows.x* groups including comp.windows.x.motif is a
good place to ask for advice on X.

-- ced

--
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.

Steffen Christgau

2005-09-29, 6:00 pm

Chuck Dillon schrieb:
> Steffen Christgau wrote:
>
>
>
> I believe your problem is you've opened it as non-blocking.
> XtAppAddInput on *nix calls select() which tells you if your process
> would block if you read from a descriptor. In non-blocking mode that's
> always true.

No, that's not the problem. In an early version of the programm I didn't
use the O_NONBLOCK flag. It was the same effect. The only difference was
that the programm was blocked as long as the pipe doesn't exist (what a
surprise *g*). Once it was created (and something was written into it? -
I don't know anymore) the callback function was called permanently, too.

> BTW, the comp.windows.x* groups including comp.windows.x.motif is a good
> place to ask for advice on X.

Thanks a lot. I'm quiet new in this metier. Usually, I work under
windows without "X" ;-). I'll ask there for any solution or advice.

Regards

Steffen