Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Anything I should know about thread safety and fprintf?



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:
http://lists.apple.com/mailman/options/darwin-dev/email@hidden

This email sent to email@hidden
References: 
 >Anything I should know about thread safety and fprintf? (From: "Jonathan del Strother" <email@hidden>)
 >Re: Anything I should know about thread safety and fprintf? (From: Terry Lambert <email@hidden>)
 >Re: Anything I should know about thread safety and fprintf? (From: "Jonathan del Strother" <email@hidden>)
 >Re: Anything I should know about thread safety and fprintf? (From: Terry Lambert <email@hidden>)
 >Re: Anything I should know about thread safety and fprintf? (From: "Jordan K. Hubbard" <email@hidden>)
 >Re: Anything I should know about thread safety and fprintf? (From: "Jonathan del Strother" <email@hidden>)
 >Re: Anything I should know about thread safety and fprintf? (From: "Jonathan del Strother" <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.