From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: Andrew Cagney Cc: Todd Whitesel , Jim Ingham , gdb@sourceware.cygnus.com, "Insight (GDB GUI)" Subject: Re: non-blocking reads/writes and event loops Date: Sun, 18 Jun 2000 22:46:00 -0000 Message-id: References: <394DAD8D.C100E36F@cygnus.com> X-SW-Source: 2000-q2/msg00286.html > Todd Whitesel wrote: > > > > > > 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"... > > Unfortunatly, unless feasible intermediate steps are identifed that show > how we can get from the eixsting GDB to this ``long term goal'' it will > just remain a long term goal :-( Almost as if planning something large was an integral part of getting it done. Strange. > > To that end, I can see several strategies. Interestingly at least one > discards the assumption that the event loop should _not_ be re-entrant. > > o invert the targets first > > This would be implemented > using something like: > > (gdb) ->do-command > -> target_xfer_memory() > -> target->request_data() > while need more data, run inner event loop > <- target-supply-data() > <- return data > > That is, the GDB core would continue > to assume that things are blocking > but the targets would internally > be implemented as non-blocking. > > Care would be needed that the internal > event loop didn't re-call the CLI et.al. > > > o invert the expression evaluator first > > In this case, legacy targets would > be wrapped so that: > > (gdb) ->do-command > -> target_memory_request() > -> target_xfer_memory () > schedule event to supply > returned data to expression evaluator > -> supply_data to expression evaluator > > > (wonder if this makes any sense). Of course there is option three, both > of the above. > > For what its worth, for some reason I have preference for the first > option - not sure why, perhaphs it is simply that I'm more familar with > targets and back-ends. > > As I noted above, one of the original design decisions for the event > loop that it not be re-entrant. The above questions that decision. And rightfully questions it, IMHO. > Another decision was that GDB's core assume no threads. Should that too > be questioned? I have no problem with using threads, i do it on a daily basis. The only issue i would have with GDB's core using threads would be that we take care not to assume that everyone has pthreads. If we go with threads, i would ask we add a simple abstraction, like most portable things using threads (Just from personal experience, Python's source comes to mind as something that works with threads, using "easy to make work on a given platform supporting threads", and provides all the thread functionality people ask for. Works on BeOS, QNX, and every other python supported platform that has threads). The question about whether we *should* use threads is a different one altogether. The real question splits into "Are there parts of gdb where we could be doing processing that isn't dependent on other processing, and we therefore are possibly wasting time on MP systems by not having each done in a thread" and "Are there parts of GDB where we could simplify code flow by using threads". > > enjoy, > Andrew >