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

Daniel Jacobowitz
2006-08-30T04:01:24Z

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