[comp.windows.x] X11R3 XtAddInput

jtc@motcad.portal.com (J.T. Conklin) (05/07/91)

I am having problems with a program written with UIM/X subprocess manager.  
What is happening is the output callback is occasionally being called after
the exit callback.  This is wierd as the subprocess doesn't have any output
unless it fails, and the subprocess executed successfully.

Since my exit callback frees memory which is subsequently dereferenced by the 
errant output callback, bad things happen.  I have attempted to limit the 
window of vulnerability through defencive programming, but there is no way
to eliminate the race condition.  I must find a way to fix the bug at its 
source.

So, with debugger in hand I started tracing through the code.  I found that
UIM/X handles subprocesses through ptys and XtAddInput.  Since the stack 
backtrace indicated that my output_handler was being called from XtNextEvent().

Time to find the tape with my X11R3 source.  I couldn't find it, but I was
able to find a copy of the X11R3 source with vendor modificiations.  I hope
that NextEvent.c hasn't been played with too much.  I compared it with my
X11R4 NextEvent.c.  From the comments and the more complex code, it seems
that there was a problem with X11R3 calling output handlers inappropriately.
Can anyone who is more familiar with the code in question confirm or deny
this conclusion?

If this is the case, then there is some questions I need answered
before I can fix NextEvent and get my application working:

  * Where can I get the X11R3 source?  (If this is answered in the FAQ,
    don't bother to answer it, since I'll read that after I finish this
    posting.)

  * I understand that OSF had patches against the X11R3 Intrinsics. Was
    NextEvent touched?  Will I be able to compile an untouched NextEvent.c
    and insert it into libXtm.a, or will I have to get the motif version.

  * Can you still licence motif 1.0?  I requested a licencing information
    pack from them, but all it contained was information on how to order 
    motif 1.1.

  * Did OSF run into this problem and fix it in 1.04 or 1.05?

If this isn't the case, I'd greatly appricate any pointers you can give me
on figuring out why my output handler is being called after my exit handler.

Thank you.

-- 
J.T. Conklin    jtc@motcad.portal.com, ...!portal!motcad!jtc