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: Thu, 24 Jan 2008 05:12:41 -0800
Please see my other posting. You are not fixing your underlying
problem here.
My personal suggested fix would be to marshal the data to a single
thread for disposition. Then your limit will be however much data you
can jam down the drain pipe plus however much data you are willing to
internally queue in your application in the marshalling process.
If your data is bursty, then a large enough queue retention pool for
the internal queue will let things work.
Think of it as pouring water in the top of a bucket with a small hole
in the bottom; as long as you only pour in as much water on average as
can drain out the hole, then burstiness is about how big you need to
make the bucket so it never overflows (in queueing theory, this is the
instantanious maxima for pool retention time).
NB: If you are doing this to log e.g. kernel events that are stalled
pending user space operations, you had better be _certain_ to exempt
everything in the code path that gets things logged from logging or
the need to go to user space on the first place.
-- Terry
On Jan 24, 2008, at 4:51 AM, Jonathan del Strother <email@hidden
> wrote:
On Jan 24, 2008 11:16 AM, Jonathan del Strother <email@hidden
> wrote:
On Jan 24, 2008 7:00 AM, Jordan K. Hubbard <email@hidden> wrote:
On Jan 23, 2008, at 5:02 PM, Terry Lambert wrote:
The only real way to talk to the system logging facility is via
syslog()
Which is how you should generate log messages only if you wish to
use
the deprecated, purely-for-backwards-compatibility interface. :-)
Please use asl(3) for all new code. It's a far better, more
flexible
interface.
Ah. I thought the standard way of system logging was just
fprintf(stderr, ... ).
I still have no idea why I should be getting stuck in write() like
that, but I've switched to asl and the problem seems to have
magically
disappeared...
Damn, spoke too soon.
Now my app gets stuck in
#0 0x94709a31 in write$NOCANCEL$UNIX2003 ()
#1 0x94700714 in asl_send ()
#2 0x946ff501 in asl_vlog ()
#3 0x946ff267 in asl_log ()
With a call to asl_log looking something like :
asl_log(aslClient, NULL, ASL_LEVEL_INFO, "%s:%d - %s",
"MillicentView.m", 236, "qc - 2.000000, 1.500000");
I attached gdb, and tried to 'finish' out of the write() frame, which
never returns. The arguments look a little odd - presumably the
function definition is along the lines of write(int fd, const void
*buffer, size_t numbytes) ? I get :
(gdb) p (char*) *(int *)($ebp+12) // buffer argument
$1 = 0x15778380 ""
(gdb) p *(size_t *)($ebp+16) // numbytes argument
$2 = 360399840
... which seems an unusually large buffer size, assuming I'm reading
that right.
I'm going to carry on hacking away at this, see if I can reduce the
problem some more.
_______________________________________________
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