Re: [rfc / remote protocol] Remote shared library events

[Jim Blandy <jimb at codesourcery dot com>]

Daniel Jacobowitz <drow@false.org> writes:
> On Wed, May 16, 2007 at 03:58:52PM -0700, Jim Blandy wrote:
>> It seems odd to me that it's an @var{n} that distinguishes the reason
>> for the stop; the @var{AA}, the @var{r}, and any other @var{r}:@var{n}
>> pairs are essentially meaningless.  I'd rather see an entirely new
>> stop reply packet type --- 'L', say --- with subsequent name/value
>> pairs, like those in a q[fs]DllInfo packet's 'm' response.
>
> I don't know why you say they're meaningless.  @var{AA} is unused, but
> @var{r} describes the exact reason for the stop (which library was
> loaded or unloaded), and other @var{r}:@var{n} pairs are treated
> exactly as they are for T packets - they supply useful registers.
> I'd have to add the expedited register support to any new reply packet
> too, which would make it basically T without the signal number; this
> version seems to complicate the protocol less.

Sorry --- of course the @var{r} associated with the dllstop isn't
meaningless.  Regarding the other pairs, I didn't realize that one
wanted expedited registers for DLL events; would we actually use them?