Re: Questions regarding notify processing.

Tom,

The alternate input source is created on application startup with:
ctrl->sys->dbInputId = XtAppAddInput (app,
ctrl->sys->socketId,
(XtPointer) (XtInputReadMask),
DbInputCB, (XtPointer) ctrl);
And, it remains throughout the duration of the application. I believe this
issue is related to your comment regarding the fact that selects are waiting
on both 3 and 4 and sometimes just one or the other.

I was using a different approach, that is, using code from one of the earlier
examples for Asynchronous command processing in the documentation. I had two
functions, one that established a few miliseconds read on the socket and, if
nothing was there, a .5 second timer was called and when that expired, we did
it all again. Using the alternate input feature of X is MUCH faster, but with
a caveat, as this thread reveals. I think I will leave the timer where it is
and see what develops when we test this before going into production. I think
the reason this pops up here is due to the fact that there are several
database accesses involved with this particular interface. Most are not
nearly as complicated as this one is.

I just need the notification in a reasonable amount of time after the Edit
operation and can even extend the timer that calls CheckForNotifies if
necessary.

You've been very helpful. Thanks...

On Friday 25 February 2005 03:51 pm, Tom Lane saith:
> Terry Lee Tucker <terry(at)esc1(dot)com> writes:
> > Sorry, I didn't know what you needed. Here is the trace:
> > (gdb) bt
> > #0 0x2b04eef2 in select () from /lib/i686/libc.so.6
> > #1 0x2adeb06c in ?? () from /usr/X11R6/lib/libXt.so.6
> > #2 0x00000001 in ?? ()
> > #3 0x08136b88 in ?? ()
> > #4 0x2adc0c47 in XtChangeManagedSet () from /usr/X11R6/lib/libXt.so.6
> > #5 0x2adc13b0 in _XtWaitForSomething () from /usr/X11R6/lib/libXt.so.6
> > #6 0x2adc23f6 in XtAppNextEvent () from /usr/X11R6/lib/libXt.so.6
> > #7 0x2adb6a7c in XtAppMainLoop () from /usr/X11R6/lib/libXt.so.6
> > #8 0x080b136a in main (argc=2, argv=0xbffff794) at main/main.c:252
>
> Well, indeed it is not stuck in PQnotifies --- it's waiting for input,
> and evidently not seeing any.
>
> Looking back at your strace, the first line shows that the connection to
> the PG server is on FD 3, since that's recognizably a NOTIFY message:
>
> recv(3, "A\0\0\0\25\0\0~3move_update\0\0C\0\0\0\rUPDAT"..., 16384, 0) = 42
>
> I suppose that the traffic on FD 4 is going to and from the X server.
>
> What seems odd is that some of the select()s are waiting on both FD 3
> and FD 4, but some on only one or the other. I'd have expected all of
> them to wait on both.
>
> I think what is happening is that the X toolkit is failing to wait on
> FD 3 at the critical point, presumably because it thinks you are no
> longer interested in input from that FD. It's been a very long time
> since I touched low-level X stuff, but perhaps you need to remind the
> toolkit repeatedly that you are interested in FD 3? Is there any path
> of control that could cancel the callback assignment for DbInputCB?
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org