Re: process.c changes causes problem with JDEbug of the JDE package

[Paul Kinnucan]

Kim F. Storm writes:
 > David Kastrup <address@hidden> writes:
 > 
 > > Uh, accept-process-output does not guarantee that you get any output
 > > that the process has not yet managed to produce.  This looks like
 > > jde-dbs.el contains a definite race condition.
 > 
 > So is there a bug in process-adaptive-read-buffering, or not?
 > 
 > > 
 > > Unless at that point of time the process has already finished and
 > > jde-dbs knows about that.  In that case there would be no point for
 > > process-adaptive-read-buffering to hold back any input anymore.
 > 

I have no idea what process-adaptive-read-buffering is supposed to do.

I wrote the code in question about five years ago when I was even more
of a neophyte than now. My idea was to try to use
accept-process-output to synchronize the JDEE's interaction with the
JDEbug debugger in order to do tasks that require execution of a
sequence of debugger commands where the next command depended on the
results of the previous command. The idea was to use accept-process-output 
to suspend Emacs until JDEbug had responed to the first command in the
sequence, then execute the next command, wait, execute the next, etc.

Unfortunately, this interface has never worked reliably. It appears
that accept-process-output sometimes misses a response from
JDEbug. This causes the JDEE to think that JDEbug never responded and
signal an error.

Consequently, my intention has been to rewrite the JDEE-JDEbug
interface to be asynchronous. My planned asynchronous interface would
support multistep tasks as follows. A multistep command would post a
listener for the results of the first step and send a command to the
debugger. The listener would then process JDEbug's output, post a
listener for the results of the next step, send the next command,
etc., resulting in a chain of interactions.

This scheme does not entail suspending Emacs while waiting for JDEbug
responses and hence would avoid, I think, the problem of missed
responses.

I have already implemented this interface for JDEE's interface with
jdb, the standard command-line debugger that comes with Sun's Java
Development Kit. It seems to work well. So I feel pretty confident
that it will work well with JDEbug, especially as JDEbug belongs to
the JDEE and hence I can adapt it to work with the proposed
asynchronous interface.

Paul


 > When does it do that?
 > 
 > > 
 > > Also it might be an idea to reset the timers for adaptive read
 > > buffering not only when one is writing to the process, but also when
 > > one is starting it, and of course after it has finished.
 > 
 > IIRC, that's what it is doing already -- timers are reset by
 > start-process and on write, and the process is ignored in adaptive
 > read buffering after it has been deactivated.
 > 
 > > 
 > > That way, typical interactive applications will never see an adverse
 > > effect from adaptive read buffering.
 > 
 > Have you observed such effects?
 > 
 > I'm probably overlooking something obvious...
 > 
 > -- 
 > Kim F. Storm <address@hidden> http://www.cua.dk
 >