> >From your description you have altered to priority of the > main thread, was
No, it is a worker thread that has the high priority. > that to the highest setting? How fast is the data coming in? Sometimes fast, sometimes slow, depending on the customer's needs. > Does it stop > and start or is it continuous? Is this over a network, input > device or comm > port? Yes, yes, yes... ;-) Sometimes the data is bursty, sometimes it is continuous. We run over serial, 100-megabit Ethernet, or custom input devices. > What comes to mind is a growable buffer that accepts > information and then if > the process hasn't emptied it will grow using more mem. If > however the data > doesn't stop and start your buffer will still eventually > overflow...... Yes, your scheme has the same problem in that eventually, if data is coming in faster than can be handled, it will overflow. But actually, the overflow isn't the problem. We do a pretty good job of handling data, and if we don't, we tell the user. That has worked for years. The problem was unrelated to that. The problem was a customer reported an intermittent crash that we couldn't reproduce in house. My guess was it had to do with some thread-unsafe code that showed up when the data collecting thread was hogging resources. My question was, "How do I prove that was the problem?" I'm thinking that if we could somehow schedule threads deterministically, I could run some tests until I found a combination that failed, then I could repeat that at will. > How fast is the slowest machine, might it be better to just say to the > people buying your app that this is the spec... or is that > unrealistic ???? There are lots of factors besides speed: HD speed, amount of RAM, nature of the data. We also allow users flexibility in buffer and file sizes. We couldn't come up with a hard number. We can tell people, "Sorry, get a faster computer" if it fails. This isn't really a big problem for us since computers are so cheap and fast, but we have to be graceful no matter what.
