Hi Jan,
> In Africa we certainly talk much faster, and LOUDER after a good
> refreshment!
> (And we talk very well as it is, you know that. In fact I wonder wether we
> do anything else)
Our Texas drawls prevent us from talking faster, but we do talk loudly
and a lot after a few long-necks.
> Now for the scary stuff:
> there IS a PROBLEM with ulibc and PREEMPT_RT.
Yep, nice link. Wonder about dietlibc? That's a completely unrelated
code base according to something I read.
> The stack problem is well known in literature, but normally the other way
> round: You run out of memory space assigning too many and too big.
> So John since you are soo good with yr toolbelt: rip out the dynamic stack
> measuring tool and measure, than double the size.
> Or maybe how about tripling the old size (since it worked a while back
> still)
Well, after all that work, I still don't have a good handle on
understanding where things are in the stack and how full it is.
You're right that it probably needn't be too much bigger. As you point
out, the change that put things over the edge was switching from
vsnprintf; fputs; to vfprintf;. In the old version, the formatting
routine and printing routine were serialized, so they didn't occupy the
stack simultaneously. In the new version, vfprintf takes care of both
functions, and worse, when it sees stderr is unbuffered, it creates a
buffer and essentially calls itself again. I'd bet 4x/64k would do it.
> And lastly I think that the whole business of error reporting by the
> program needs careful consideration. the problem came about when Epler
> broke out the error reporting to the operator and through a fifo to the
> user interface so he/we can internationalize it. Which is good off course.
> So here is a thought:
> Why is not all error reporting done that way! Some errors are then just
> marked "system error xx" which would almost automatically cause a bug
> report to be filed.
Yes, this sounds like the right way to do it. Also, the Buesch patches
have some plain ol' 'printf' statements in there, not indented properly,
not running through the rtapi msg facility. I bet those were debugging
statements that weren't removed.
> Last question to you experts: what latencies are you measuring?
50uS on my x86_64 workstation with no tuning whatsoever. USB keyboard,
no BIOS settings, etc. I'll report back when it's running on the
intended production machine.
John
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
