Re: Merge of nickrob-async-20060513 to mainline?

[Daniel Jacobowitz <drow@false.org>]

On Wed, Aug 30, 2006 at 03:18:58PM +1200, Nick Roberts wrote:
> If people are willing to review it then that is clearly preferable.  If
> not, then after passing the testuite, putting it in the repository would
> seem to be a good way to test it.  If it caused too much disruption then
> it could be reverted fairy easily and there is plenty of time before the
> next release.

I'll wait to see what other developers have to say, but I think we
should at least make an effort to review it.

>  > How big are the changes relative to mainline (diffstat)?
> 
> A few extra files and a sprinkling of extra lines/if clauses (to test
> if asynchronous) in twenty or so files.  I could run diffstat but I'm
> not familiar with it.

Just generate the diff between your mergepoint and branch, and then
pipe it to diffstat, assuming you've got it installed.

> Well, it should be invisible for anything but i386-linux-gnu and work as before
> on i386-linux-gnu unless "--async" is specified.  To that extent it shouldn't
> interfere with anyone not interested in using it.  However, I may used the
> wrong files to try to achieve this.  There is also a file called README.async
> in the branch.

Well, I meant from an internals perspective - like, a patch just
summarizing the interface changes, if the whole patch is too big to
post at once.

> Also it still uses pthreads.  You said previously that it should be done
> in one process and, following a remark from Jim Ingham, that ptrace is
> non-blocking.  AFAICS the problem is that wait *is* blocking and I can't
> see of a way to deal with that without using another thread.

Ah, but wait is non-blocking.  You have to (A) use WNOHANG, and (B) be
careful to handle asynchronous SIGCHLD events.  It's not especially
difficult, I don't think, but the async event loop in gdb has always
confused me; we'll have to figure out how to gather up sigchld/wait
events.

-- 
Daniel Jacobowitz
CodeSourcery