Re: [Cgdb-devel] TGDB structures

[Bob R. <bo...@br...>]

On Wed, Sep 17, 2003 at 03:25:26PM -0400, Alain Magloire wrote:
> ..
>=20
> > > it is not very complicated either: a non-blocking way of verifying wh=
ether
> > > your pointer is still OK before writing to it is available on all ix8=
6=3D20
> > > platforms since the 486; it's available on the Sparc (though I don't =
know
> > > since when) and on many other chips. And if a non-blocking way to do =
it
> > > is not available, a fine-grained blocking implementation can be (almo=
st) =3D
> > just
> > > as fast.
> >=20
> > I think leaving out the possibility of threading could be a mistake.
> > We should probably at least design TGDB in a way where it is thread
> > safe capable. Even if it doesn't support multi-threaded applications.
> > I don't know much about threaded applications, but it seems like Ronald
> > is stating the an ADT would support threads a little better that a
> > simple linked list. ( depending on the implementation of the ADT )
> >=20
> > Any other considerations?
> >=20
> > I really hope to only do this once. As I am tired of going back to
> > change things that were not well thought out in the first place. The
> > structures are particularly important because they are really the only
> > thing that will affect all front ends.
> >=20
>=20
> 8-)
> You have to realize you will never get things right the first time,
> simply not possible.
> My point was to bring this to your attention as you were asking
> for feeback.
>=20
> The MI front end that we did is "Thread-safe" but not "Reentrant".
> There is a distinction.  It's thread-safe that you can use
> multiple thread and the library will serialize the requests if
> need be ore does not carry any state that can make the use of
> thread impossible.  It is not "reentrant" meaning that it serialize
> commands and trying to recall/reenter a command may mean deadlock.
>=20
> That sayd, If you say that in version 1.0 of tgdb you folks
> will not worry about threads and will tackle the issue only in
> 2.0 ... that's certainly reasonnable.  Some issues can be
> deal better with some later version, when the direction is better underst=
ood.
>=20
> my 0.0002 canadian.

Good point. I think we will worry about threads in 2.0 like you
suggested. However, we will try to write it in a way that is easy to
change to be "Thread-safe" and "Reentrant".

Since there is no front end that relies on this and there is a ton of
other work to do. Like the actual MI integration. :)

Bob Rossi