Re: Anything I should know about thread safety and fprintf?
Re: Anything I should know about thread safety and fprintf?
- Subject: Re: Anything I should know about thread safety and fprintf?
- From: Terry Lambert <email@hidden>
- Date: Wed, 23 Jan 2008 17:02:48 -0800
On Jan 23, 2008, at 2:18 PM, Jonathan del Strother wrote:
On Jan 23, 2008 10:06 PM, Terry Lambert <email@hidden> wrote:
This is thread B blocking waiting to acquire the lock currently held
by thread A.
You need to figure out why thread A is blocking. Why it's blocking
will depend on what type of thing the underlying descriptor for the
FILE * being written happens to be attached to.
This will most likely boil down to a network connectivity problem, a
server problem, or a problem with another program that you are trying
to talk to over a pipe/UNIX domain socket/whatever (i.e. a bug in
your
code).
Hmm. Well I'm not reopening stderr anywhere, so it ought to still be
logging to /var/logs/system.log, or to Xcode's run window. Neither of
which ought to be blocking like that. (Actually, I'm not sure whether
or not I've ever reproduced this when running outside of Xcode. I'll
try it out tomorrow, see if it makes any difference)
Uh, "logging" how?
The only real way to talk to the system logging facility is via
syslog(), not stdout/stderr (system logging is a formatted interface;
there's an ident that's set when it's opened, along with logging
options and a facility code. The syslog() itself takes a priority, a
message, and a formatting string, plus any parameters, which are
internally formatted using vsyslog(). None of those are in your stack.
If you are writing to stdout/stderr to go to the log file, then you
are either writing to a pty that you opened and made into the console
pty via:
int enable = 1;
...
ioctl(fd, TIOCCONS, &enable);
on the slave side of the device (requires root privilege!), or you are
talking via a pipe or socket to something that itself uses syslog()...
and that something isn't reading its input stream in order to unblock
your write.
So the problem is either that the something you are writing to is
broken, or the something doing the writing is not letting the
something being written to drain its input buffer, because it's
generating so much data that it's impossible for whatever it's talking
to to ever be able to keep up.
If it's the latter (you are generating too much output for what you
are talking to to keep up), then it only looks blocked because that's
most often its state -- it's allowing other things to make
(slooooooooow) progress, but you aren't really seeing it because your
sampling isn't happening over a long enough interval.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden