2002 2003 2004 2005 2006 2007 <2008> 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 2002 2003 2004 2005 2006 2007 <2008> 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: errlogVprintf does not print messages to console |
From: | Eric Norum <[email protected]> |
To: | Andrew Johnson <[email protected]> |
Cc: | Core-Talk <[email protected]>, Mark Rivers <[email protected]> |
Date: | Mon, 3 Nov 2008 15:25:45 -0600 |
On Nov 3, 2008, at 2:40 PM, Andrew Johnson wrote:
The decision comes down to how heavily you weight the expectations that you mention in the first paragraph above. As you pointed out, the developer's guide does state (or at least imply pretty strongly) that......The middle sentence "by the same thread" is important in understanding why the existing code is like it is. Developers don't particularly like it if their errlogPrintf() output doesn't come out immediately; they expect the sequenceof calls printf("A\n"); errlogPrintf("B\n"); printf("C\n");to generate "A" "B" and "C" in order, which is why the "by the same thread" part was added. Now if epicsThreadIsOkToBlock() returns false we must avoid blocking the thread (any kind of printf() to a file descriptor is potentially blocking) so we have no choice but to punt the printf() to the errlogThread, but where blocking isn't a problem it's nicer to do the printf() directly inthe calling thread. ..............The question I have for any core-talk readers still paying attention is:How important is it that errlogPrintf() and friends directly call fprintf(stderr) when called in a thread that is allowed to block? My inclination would be to do what Lewis proposes and do all the console output from the errlogThread, but that would often cause the example above to output "A", "C" and then later "B".
printf("A\n"); errlogPrintf("B\n"); printf("C\n");will generate "A" "B" and "C" in order. Now this promise is to be rescinded. About par for the course at this time of year in this country, I suppose.........
I think that it is fairly easy to argue that there should not be any expectation that errlogPrintf output appear in any fixed relation to printf/fprintf output.
-- Eric Norum <[email protected]> Advanced Photon Source Argonne National Laboratory (630) 252-4793