site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com -- Terry 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() 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 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 (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... 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. On Jan 24, 2008, at 4:51 AM, Jonathan del Strother <maillist@steelskies.com
wrote: On Jan 24, 2008 11:16 AM, Jonathan del Strother <maillist@steelskies.com wrote:
On Jan 24, 2008 7:00 AM, Jordan K. Hubbard <jkh@apple.com> wrote: 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... ... which seems an unusually large buffer size, assuming I'm reading that right. This email sent to site_archiver@lists.apple.com