On Sat, 2009-05-23 at 21:06 -0700, David Brownell wrote: > On Saturday 23 May 2009, Zach Welch wrote: > > > > > Considering that USB bulk transfers are "best effort" and might easily > > > be delayed by concurrent activity to a USB disk or webcam ... a single > > > second seems absurdly short. Even if the device were guaranteed to be > > > able to respond that quickly. > > > > Right, but that does not mean we should simply throw the program into a > > blocking call with a longer timeout. I would rather see the device make > > a try using a _shorter_ timeout and allow for other processing to occur > > in between retries. > > "Retry"?
Well, I am thinking of the J-Link code in particular, which I suppose is more of a "continuation" condition. > I'd rather see the event loops structured better, so that each activity > gets its own thread. That would move from those error-prone presumptions > that manually timesliced event loops can scale. I like the idea of threads, but that opens a new dimension of problems for embedded systems (though none supported... today). It would be nice to be able to run OpenOCD in a single thread. > I see messages about needing to increase some GDB timeout/interval. But > that's foolishness, since I'm not even working with GDB when they start > spamming me. The core problem has nothing to do with GDB, and everything > to do with a weak concurrency model. I agree. This is what I meant by retries. If we're working on the single thread model, no event/action can be allowed to take more than MAX_TIME_SLICE, or you see those sorts of problems. I thought that libusb worked in non-blocking mode, but perhaps I was wrong.... > Too bad that can't be fixed before the next release. ;) Yeah. These are Big Changes. Cheers, Zach _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
