Hi Michel,
Yes, I am just using that code as an example of a more general
situation of where I might need a private event loop. As another
example, I might need to fork a child to do something that could
take a while (like invoking another program that will be slow
to complete), so I would do something like this:
void callback_func(Widget w, XtPointer client_data, XtPointer call_data)
{
/* ... */
if ((cpid = fork()) < 0) {
perror("fork");
return;
}
if (cpid != 0) {
/* Parent process */
while (waitpid(cpid, &wstat, WNOHANG) != cpid) {
if (cpid < 0) {
perror("waitpid");
break;
}
/* Handle some X events while we wait */
while (XtAppPending(app_context))
XtAppProcessEvent(app_context, XtIMAll);
}
/* Check wstat for child exit status, and take
* appropriate action, etc.
*/
if (WIFEXITED(wstat)) {
/* ... */
} else if (WIFSIGNALED) {
/* ... */
}
return;
}
/* Child process */
/* ... do lengthy work ... */
exit(exit_status);
}
Anyway, I guess wild stack growth is a mild concern, but I have not
seen that to be a big issue. I was just checking to make sure
it's safe to have an event loop within a callback function or
timeout function.
As for the XIO and unexpected async reply errors, the particular program
is not multithreaded, and I have most signals set to SIG_IGN, so it's
not signal handlers wreaking havoc... It does have code that fork
children as in the example above, but the child process do not do
any Motif, Xt or Xlib calls. What else should I be looking for to
find the cause?
-Ti
> Ti Kan wrote:
> > Question: Can the XtAppProcessEvent() function be called from a
> > event or timer callback function? I.e., simply put, can
> > an Xt callback function itself have an event handling loop?
> >
> > I have an app that has a XtAppMainLoop(), but some of the work in
> > the callback function could take a long time (i.e., network
> > I/O, etc). So, is it safe for the callback function itself to do
> > something like select() on the data being waited on, while itself having
> > an event loop that looks something like this, so that the app doesn't
> > appear frozen:
> >
> > void callback_func(Widget w, XtPointer client_data, XtPointer call_data)
> > {
> > /* ... */
> >
> > do {
> > FD_ZERO(&efds);
> > FD_ZERO(&rfds);
> > FD_SET(fd, &rfds);
> >
> > to.tv_sec = 0;
> > to.tv_usec = 50000;
> > ret = select(fd+1, &rfds, NULL, &efds, &to);
> >
> > while (XtAppPending(app_context))
> > XtAppProcessEvent(app_context, XtIMAll);
> > } while (ret == 0);
> >
> > /* ... */
> > }
> >
> > Sorry about this somewhat off-topic question, but I haven't been able
> > to get a definitive answer from the various X docs and manuals.
> > The XtAppProcessEvent man page seems to imply that this is ok, but
> > it's not clear that the function is actually safe for recursion at
> > some level.
> >
> > I tested this and it seems to work, but some users of my app gets
> > XIO errors and unexpected async reply errors that I could not reproduce.
> >
> > Hope someone could shed some light on this.
> >
> > -Ti
>
> First of all, you dont *need* to do this, you could use XtAppAddInput.
> Then IO events are handled the same way as others, and you wont have
> that 50ms delay before X events can be processed.
>
> Next, in general, you *can* have a private events loop in a callback.
> There should not be any problem *provided* none of the events can
> trigger the same callback again. Example (good): the callback for a
> PushButton manages a dialog and has its own loop until the dialog is
> unmanaged. However, if the callback *is* triggered again, then you could
> have a wild stack growth.
>
> As for your XIO errors etc..., I dont think that's related. Such
> problems usually happen in a multi-threaded program, is yours like that?
>
> --
> Michel Bardiaux
> Peaktime Belgium S.A. Bd. du Souverain, 191 B-1160 Bruxelles
> Tel : +32 2 790.29.41
_______________________________________________
Lesstif mailing list
[EMAIL PROTECTED]
https://terror.hungry.com/mailman/listinfo/lesstif
