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"? 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 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. Too bad that can't be fixed before the next release. ;) _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
