Re: RFC: MI output during program execution

[Daniel Jacobowitz <drow@false.org>]

On Mon, Oct 03, 2005 at 02:37:56PM -0700, Stan Shebs wrote:
> Remote async can do it (more-or-less) portably because both the user
> and target interaction happen through file descriptors, and the usual
> API supports multiplexing. Darwin is problematic because you have
> to get some data from events and the like that only have blocking
> calls to monitor, so you need a thread per blocking syscall.

If Darwin's really got no non-blocking way to do this, then it'll need
either threading, or a helper process which handles the blocking events
and feeds them back to a file descriptor.  Threading is probably
easier, I agree.

> >This is a little more complicated to design, however, it's got less
> >complexity at runtime.  I've spent enough of my life using GDB on
> >systems where pthreads didn't work that I don't want to make GDB
> >dependent on them.
> >
> Ideally you'd push the thread/multiplex decision down into target code,
> but this would be a semi-ambitious rework to event-loop.c. It might
> not matter though, if Darwin (and other configs maybe) can keep using
> their own thread-hell code, while something like Linux can assume file
> descriptors for inferior monitoring and thus use the general mechanism.

I can't see any immediate reason why the upper levels need to know
about this.  I still need to take a look at Nick's patch, though.

-- 
Daniel Jacobowitz
CodeSourcery, LLC