Re: non-blocking reads/writes and event loops

[Todd Whitesel <toddpw@windriver.com>]

> However, threads may need to be used in the case where you only have a
> blocking API to control the inferior, but in that case all you are doing is
> using threads to fix this local deficiency, not pushing it into the gdb
> architecture.  I think this is managable.

Agreed. If the API designers are dumb enough to trust threads absolutely,
and don't give us an option, then well, that's life.

-- 
Todd Whitesel
toddpw @ windriver.com
From jimb@zwingli.cygnus.com Wed Jun 14 15:48:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb@sourceware.cygnus.com
Subject: Re: [PATCH] More updates to FXSR/SSE support in 2.4.0-test1
Date: Wed, 14 Jun 2000 15:48:00 -0000
Message-id: <nppupjhoam.fsf@zwingli.cygnus.com>
References: <E130wkg-0000uJ-00@the-village.bc.nu> <394428DD.A2EFC21B@precisioninsight.com> <200006120002.e5C02mv14043@delius.kettenis.local>
X-SW-Source: 2000-06/msg00129.html
Content-length: 411

> If there are major problems, it might be wise to choose a different
> name for the PTRACE_{GET,SET}XFPREGS requests to avoid confusion.
> That way, nobody will end up with a non-functional GDB (of course the
> blame lies entirely with the GDB team for this mess).

Well, the blame lies specifically with me, I assume.  I did the
original SSE debugging support.

How should I have done this to avoid the mess?
From ac131313@cygnus.com Wed Jun 14 18:37:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Todd Whitesel <toddpw@windriver.com>
Cc: Jim Ingham <jingham@apple.com>, gdb@sourceware.cygnus.com, "Insight (GDB GUI)" <insight@sourceware.cygnus.com>
Subject: Re: non-blocking reads/writes and event loops
Date: Wed, 14 Jun 2000 18:37:00 -0000
Message-id: <394832F2.39D46459@cygnus.com>
References: <200006141746.KAA29364@alabama.wrs.com>
X-SW-Source: 2000-06/msg00130.html
Content-length: 1910

Todd Whitesel wrote:
> 
> > However, threads may need to be used in the case where you only have a
> > blocking API to control the inferior, but in that case all you are doing is
> > using threads to fix this local deficiency, not pushing it into the gdb
> > architecture.  I think this is managable.
> 
> Agreed. If the API designers are dumb enough to trust threads absolutely,
> and don't give us an option, then well, that's life.

For what it is worth, here is the ``It is hard'' reason number two:

In addition to the expression evaluator, every physical target (that is
the bit that knows how to read/write memory and registers) needs to be
inverted.  The basic programming model used when developing them
requiring a full rewrite.

At present a memory/register IO looks like (vaguely):

	event-loop
	   tty event: (gdb) print ...
		-> expression-evaluator
		    -> target->read()
		        -> os/remote->read()
		        <- data
		    <- data
		<- evaluate
	    print

at the target level, since we are inverting things, it would need to be
broken down into several transactions:

	event-loop
	    tty-event: (gdb) print ...
		-> expression-evaluator
		    -> target->request_read ()
		        -> os/remote->request_read ()

	event-loop
	    os/remote-event: some data ready
		-> os/remote->supply_some_of_data()

	event-loop
	    os/remote-event: some data ready
		-> os/remote->supply_rest_of_data() (all data ready)
		    -> target->supply_data()
			->expression_evaluator->supply_data()

	event-loop
	     ->expression-evaluator->display()

(please don't nit-pick on the detail :-).  The point being that you are
introducing a fundamentally different programming model into _all_
levels of GDB.  You are no longer using procedures but instead passing
around messages and writing state machines or similar.  All of which are
not mechanical.

Just making certain that your eyes are open :-)

	Andrew
From toddpw@windriver.com Wed Jun 14 18:49:00 2000
From: Todd Whitesel <toddpw@windriver.com>
To: ac131313@cygnus.com (Andrew Cagney)
Cc: toddpw@windriver.com (Todd Whitesel), jingham@apple.com (Jim Ingham), gdb@sourceware.cygnus.com, insight@sourceware.cygnus.com ("Insight (GDB GUI)")
Subject: Re: non-blocking reads/writes and event loops
Date: Wed, 14 Jun 2000 18:49:00 -0000
Message-id: <200006150149.SAA00358@alabama.wrs.com>
References: <394832F2.39D46459@cygnus.com>
X-SW-Source: 2000-06/msg00131.html
Content-length: 365

> > Agreed. If the API designers are dumb enough to trust threads absolutely,
> > and don't give us an option, then well, that's life.
> 
> For what it is worth, here is the ``It is hard'' reason number two:
...
> Just making certain that your eyes are open :-)

No doubts about that. That's why I said "long term goal"...

-- 
Todd Whitesel
toddpw @ windriver.com
From guo@cup.hp.com Thu Jun 15 09:59:00 2000
From: Jimmy Guo <guo@cup.hp.com>
To: dan@cgsoftware.com
Cc: gdb@sourceware.cygnus.com
Subject: rfc: remove gdb.hp/gdb.aCC/namespace.exp test
Date: Thu, 15 Jun 2000 09:59:00 -0000
Message-id: <Pine.LNX.4.10.10006150956450.801-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-06/msg00132.html
Content-length: 192

Daniel,

Since you've moved namespace.exp & namespace.cc to gdb.c++, the copies in
gdb.hp/gdb.aCC are redundant.  I can remove these two files if no one
objects.

- Jimmy Guo, guo@cup.hp.com