January 2008 - Darwin-dev - lists.apple.com

Re: Anything I should know about thread safety and fprintf?
by Jonathan del Strother 24 Jan '08

24 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=h3QnrNuWKti5Njyzs9V3ZNGgBx30w9A+hSbPj2fuuus=; b=ObGZhqL2lTwQRxwC6J6996MGp6RaMyZWF2EiXeaj5ZVqgwQkg3twahRwxBhLlW88tUpwzHCBbtRFOnK9PUaTt4IAW/RTuHkfkf93EAHej5IZclYSOu7LmgfQYvzjplDsTCV7HL048VuEXaNVgGaHC9Q0nosMO6FcTbfWOmTrY54= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=b2DbKIR4ZF83WgSc2Q062kKK+FwJwEBilwQrZaa1SdrdgQYzGIbAjqAAJfYwpEpdvuUeN7ikiAuIf0+y9EGLLKTgR5i3f5PXPzb07avelEh+aemUNg1JVGmSEU9ne/+HovJIQJtzSbgJ0Hi09zRK5c7/xLK1E9UCh+OSLcsGJeI= On Jan 24, 2008 7:00 AM, Jordan K. Hubbard <jkh(a)apple.com> 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... Thanks for the help, Jon _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Anything I should know about thread safety and fprintf?
by Jordan K. Hubbard 24 Jan '08

24 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Jan 23, 2008, at 5:02 PM, Terry Lambert wrote: - Jordan _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Anything I should know about thread safety and fprintf?
by Terry Lambert 24 Jan '08

24 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com 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. 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? int enable = 1; ... ioctl(fd, TIOCCONS, &enable); -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Jan 23, 2008, at 2:18 PM, Jonathan del Strother wrote: On Jan 23, 2008 10:06 PM, Terry Lambert <tlambert(a)apple.com> wrote: 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). 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: 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. This email sent to site_archiver(a)lists.apple.com

1 0

perl 5.8.8, backtick execution and leopard
by Nathan Herring 23 Jan '08

23 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AcheGZUs4/TXfs9jtEOWkda9ia9ncw== Thread-topic: perl 5.8.8, backtick execution and leopard _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Anything I should know about thread safety and fprintf?
by Jonathan del Strother 23 Jan '08

23 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=M6LqaremV2bkXq4exwOiER2tBBnyA8NcJjPQkFOPvE8=; b=hw++gWWnpZ06b9Ic58SjDhHpHr0Px7DnSKVjJ3fs4Z3zIAqEcYcTXiIfwe9aWpmnvUHRUvQwOjOLih6mKXbRxtbQuGNFZ4Eb/BcxO/8e8lkt1a7eKAdgGEHg0/6lQsPCNh6sSJQw3gv1MllGDtoV8TWjtLQWJMXK+7fA/8tJrMQ= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=fAK/Sm4sWqOCZfMWKIw6hkiKfJAbBI7f262/Uey6Dj9YCkBiDNrcPBONaOGd8g3Cr/RgiSn/OuP2aCnoBw+oyYSg5S8WmGbIwiJo/FvqxT/KJIfjNkYxl4v5V0k+6M1tnHViMPO+H+QCVaKA8NSfU8ZEz8UEigZaBtUqpt2rZX0= On Jan 23, 2008 10:06 PM, Terry Lambert <tlambert(a)apple.com> wrote: > On Jan 23, 2008, at 11:48 AM, Jonathan del Strother wrote: > > I keep running into an apparent deadlock within fprintf. I can > > semi-reliably reproduce it within my application, but have been > > totally unable to reduce the problem to a smaller test case. > > > > In a nutshell, I have two threads calling this - > > fprintf(stderr, "%s:%d - %s\n", [fileBaseName > > cStringUsingEncoding:NSASCIIStringEncoding], lineNumber, > > [formattedMessage cStringUsingEncoding:NSASCIIStringEncoding]); > > > > resulting in the following stack trace. The first thread just sits in > > write$NOCANCEL$UNIX2003() for ever. > > > > thread A : > > > > #0 0x94709a36 in write$NOCANCEL$UNIX2003 () > > #1 0x9470998e in _swrite () > > #2 0x947098bb in __sflush () > > #3 0x946d4ac8 in __vfprintf () > > #4 0x94709603 in vfprintf_l () > > #5 0x94709597 in fprintf () > > This is thread A blocked waiting for a write to complete, because it's > writing to a pipe, socket, network file over a protocol for which the > server is not currently responding, or other blocking operation. > > While it's waiting for this write to complete, it's holding a > serialization lock on the stdio FILE that it's writing to. > > > > thread B : > > #0 0x946d392e in semaphore_wait_signal_trap () > > #1 0x946db405 in pthread_mutex_lock () > > #2 0x94713383 in flockfile () > > #3 0x947095e6 in vfprintf_l () > > #4 0x94709597 in fprintf () > > 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) _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Anything I should know about thread safety and fprintf?
by Terry Lambert 23 Jan '08

23 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com I keep running into an apparent deadlock within fprintf. I can semi-reliably reproduce it within my application, but have been totally unable to reduce the problem to a smaller test case. In a nutshell, I have two threads calling this - fprintf(stderr, "%s:%d - %s\n", [fileBaseName cStringUsingEncoding:NSASCIIStringEncoding], lineNumber, [formattedMessage cStringUsingEncoding:NSASCIIStringEncoding]); resulting in the following stack trace. The first thread just sits in write$NOCANCEL$UNIX2003() for ever. thread A : #0 0x94709a36 in write$NOCANCEL$UNIX2003 () #1 0x9470998e in _swrite () #2 0x947098bb in __sflush () #3 0x946d4ac8 in __vfprintf () #4 0x94709603 in vfprintf_l () #5 0x94709597 in fprintf () thread B : #0 0x946d392e in semaphore_wait_signal_trap () #1 0x946db405 in pthread_mutex_lock () #2 0x94713383 in flockfile () #3 0x947095e6 in vfprintf_l () #4 0x94709597 in fprintf () -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Jan 23, 2008, at 11:48 AM, Jonathan del Strother wrote: This is thread A blocked waiting for a write to complete, because it's writing to a pipe, socket, network file over a protocol for which the server is not currently responding, or other blocking operation. While it's waiting for this write to complete, it's holding a serialization lock on the stdio FILE that it's writing to. 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). This email sent to site_archiver(a)lists.apple.com

1 0

Re: Anything I should know about thread safety and fprintf?
by Jonas Maebe 23 Jan '08

23 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 23 Jan 2008, at 20:48, Jonathan del Strother wrote: I keep running into an apparent deadlock within fprintf. I can semi-reliably reproduce it within my application, but have been totally unable to reduce the problem to a smaller test case. In a nutshell, I have two threads calling this - fprintf(stderr, "%s:%d - %s\n", [fileBaseName cStringUsingEncoding:NSASCIIStringEncoding], lineNumber, [formattedMessage cStringUsingEncoding:NSASCIIStringEncoding]); resulting in the following stack trace. The first thread just sits in write$NOCANCEL$UNIX2003() for ever. Jonas _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Do you change stderr to point somewhere specific, and if not, do you pipe the output of your program to some other program? (e.g. a pipe has a buffer of 4KB and once it is full, your program will block writing until the other side empties the pipe). Also, if this is a GUI app (or a daemon?), the stderr stuff may go by default to the console or system log, filling up some disk (although I assume that's unlikely in this case). Anyway, the problem you have is most likely not caused by fprintf not being thread safe, but by the write operation blocking for some reason. This email sent to site_archiver(a)lists.apple.com

1 0

Anything I should know about thread safety and fprintf?
by Jonathan del Strother 23 Jan '08

23 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; bh=6KKgDFPJrinvQq8n5tde9/4y1EV7SKOuxN80UW+cc7M=; b=cWrdQqO5fZgII34q2EAW9EZiEtxrLb0/eH6vFe3mgh1s0jlHsbzU4wkgPlMy/3aFnnLBvb/Wwiu58zQhVjYXNFnjK8MfxzHczzhTqIbSnvsJfZcRtUkFtqqU5/+PEW67IngNMmGgAZD+fCpWpujC0k6yNv6OcAx8V1M0XPy6FDg= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=Vx6MN66TU9wYkPukzX8FdYZAIxs2Kg6abl7ShpOZgIcbQz77e7wzREknEgv6jsJma3s+pVPipwHOZTXbk26BoWnasnJK/eg3uJO5xCj0K0Fs2sa/0P7Za47n0adn81wrXrfvc+QApxxO8DIOgIa2RshZYBHSyHJcizvSxoknFsg= I keep running into an apparent deadlock within fprintf. I can semi-reliably reproduce it within my application, but have been totally unable to reduce the problem to a smaller test case. In a nutshell, I have two threads calling this - fprintf(stderr, "%s:%d - %s\n", [fileBaseName cStringUsingEncoding:NSASCIIStringEncoding], lineNumber, [formattedMessage cStringUsingEncoding:NSASCIIStringEncoding]); resulting in the following stack trace. The first thread just sits in write$NOCANCEL$UNIX2003() for ever. thread A : #0 0x94709a36 in write$NOCANCEL$UNIX2003 () #1 0x9470998e in _swrite () #2 0x947098bb in __sflush () #3 0x946d4ac8 in __vfprintf () #4 0x94709603 in vfprintf_l () #5 0x94709597 in fprintf () thread B : #0 0x946d392e in semaphore_wait_signal_trap () #1 0x946db405 in pthread_mutex_lock () #2 0x94713383 in flockfile () #3 0x947095e6 in vfprintf_l () #4 0x94709597 in fprintf () (full stack trace below) The arguments to fprintf typically boil down to something like : fprintf(stderr, "%s:%d - %s\n","BBDownloader.m", 56, "Downloading /assets.xml from http://demo.host.com"); Poking around with gdb seems to confirm this. My arguments to fprintf seem fine, all the strings are null terminated and sensible lengths, etc etc. That on it's own doesn't seem enough to reproduce the problem, however - eg a test app with two threads constantly logging to stderr will happily run all night without problems. Scanning through the darwin source, fprintf appears to be thread safe. Any ideas what might cause that write() method to just block for ever? Any suggestions on this would be massively appreciated - I've been seeing this problem for around the past 5 months now and have wasted days trying to track down the problem Jonathan del Strother Appendix A - Full stack trace Thread 18 (process 7956 thread 0xa603): #0 0x946daace in __semwait_signal () #1 0x946da94f in nanosleep$UNIX2003 () #2 0x000b439b in bbSleep (secs=0.033304762335319538) at /Users/jon/Developer/BBView/src/MillicentView.m:105 #3 0x000b42bd in -[MillicentView drawLoop] (self=0x157df6b0, _cmd=0xcb5e8) at /Users/jon/Developer/BBView/src/MillicentView.m:427 #4 0x9358004d in -[NSThread main] () #5 0x9357fbf4 in __NSThread__main__ () #6 0x94704075 in _pthread_start () #7 0x94703f32 in thread_start () Thread 17 (process 7956 thread 0xa403): #0 0x946d3946 in semaphore_timedwait_signal_trap () #1 0x947051cf in _pthread_cond_wait () #2 0x94706a53 in pthread_cond_timedwait_relative_np () #3 0x96b79ba4 in CVDisplayLink::waitUntil () #4 0x96b7a566 in CVDisplayLink::runIOThread () #5 0x94704075 in _pthread_start () #6 0x94703f32 in thread_start () Thread 16 (process 7956 thread 0x9b07): #0 0x946daace in __semwait_signal () #1 0x94705306 in _pthread_cond_wait () #2 0x94704ced in pthread_cond_wait$UNIX2003 () #3 0x94175f32 in glvmDoWork () #4 0x94704075 in _pthread_start () #5 0x94703f32 in thread_start () Thread 15 (process 7956 thread 0x9503): #0 0x946d38e6 in mach_msg_trap () #1 0x946db0dc in mach_msg () #2 0x90014a5d in glcDebugListener () #3 0x94704075 in _pthread_start () #4 0x94703f32 in thread_start () Thread 14 (process 7956 thread 0x8d03): #0 0x946d392e in semaphore_wait_signal_trap () #1 0x946db405 in pthread_mutex_lock () #2 0x94713383 in flockfile () #3 0x947095e6 in vfprintf_l () #4 0x94709597 in fprintf () #5 0x0007ef40 in BBDetailedLogWithVA (level=BB_LOG_INFO, lineNumber=249, fileName=0x2580c "/Users/jon/Developer/MillicentPro/src/AssetManager.m", methodName=0x259c4 "-[AssetManager downloader:succeededWithData:]", message=0x2ca18, args=0xb066b184 "\020?|\025ST??\004\a") at /Users/jon/Developer/BBUtilities/Src/BBLogger.m:41 #6 0x0007efb5 in BBDetailedLog (level=BB_LOG_INFO, lineNumber=249, fileName=0x2580c "/Users/jon/Developer/MillicentPro/src/AssetManager.m", methodName=0x259c4 "-[AssetManager downloader:succeededWithData:]", message=0x2ca18) at /Users/jon/Developer/BBUtilities/Src/BBLogger.m:51 #7 0x0000d2b0 in -[AssetManager downloader:succeededWithData:] (self=0x136c80, _cmd=0x85b56, aDownloader=0x157c4060, downloadedData=0x17037060) at /Users/jon/Developer/MillicentPro/src/AssetManager.m:249 #8 0x000705a8 in -[BBDownloader connectionDidFinishLoading:] (self=0x157c4060, _cmd=0x95f235c4, connection=0x17037090) at /Users/jon/Developer/BBUtilities/Src/BBDownloader.m:178 #9 0x935e5357 in -[NSURLConnection(NSURLConnectionReallyInternal) sendDidFinishLoading] () #10 0x935e52e4 in _NSURLConnectionDidFinishLoading () #11 0x9546f897 in sendDidFinishLoadingCallback () #12 0x9546c9ca in _CFURLConnectionSendCallbacks () #13 0x9546c1db in muxerSourcePerform () #14 0x969fe64e in CFRunLoopRunSpecific () #15 0x969fed38 in CFRunLoopRunInMode () #16 0x935b45b5 in -[NSRunLoop(NSRunLoop) runMode:beforeDate:] () #17 0x00082967 in -[ThreadWorker startThread:] (self=0x157c42d0, _cmd=0x8b58c, callingPortArray=0x157c43d0) at /Users/jon/Developer/BBUtilities/Src/ThreadWorker.m:212 #18 0x9358004d in -[NSThread main] () #19 0x9357fbf4 in __NSThread__main__ () #20 0x94704075 in _pthread_start () #21 0x94703f32 in thread_start () Thread 13 (process 7956 thread 0x4243): #0 0x946d38e6 in mach_msg_trap () #1 0x946db0dc in mach_msg () #2 0x969fe0fe in CFRunLoopRunSpecific () #3 0x969fed38 in CFRunLoopRunInMode () #4 0x954b4d45 in _KeychainThread () #5 0x94704075 in _pthread_start () #6 0x94703f32 in thread_start () Thread 12 (process 7956 thread 0x8303): #0 0x00000000 in ?? () Cannot access memory at address 0x4 Thread 11 (process 7956 thread 0x8203): #0 0x00000000 in ?? () Cannot access memory at address 0x4 Thread 10 (process 7956 thread 0x8103): #0 0x00000000 in ?? () Cannot access memory at address 0x4 Thread 9 (process 7956 thread 0x8003): #0 0x9473c95a in __workq_ops () #1 0x9473e052 in workqueue_exit () #2 0x9473c98a in start_wqthread () Thread 8 (process 7956 thread 0x7c07): #0 0x946d3946 in semaphore_timedwait_signal_trap () #1 0x947051cf in _pthread_cond_wait () #2 0x94706a53 in pthread_cond_timedwait_relative_np () #3 0x935c5f9c in -[NSCondition waitUntilDate:] () #4 0x935c5db0 in -[NSConditionLock lockWhenCondition:beforeDate:] () #5 0x935c5d15 in -[NSConditionLock lockWhenCondition:] () #6 0x961bdc19 in -[NSUIHeartBeat _heartBeatThread:] () #7 0x9358004d in -[NSThread main] () #8 0x9357fbf4 in __NSThread__main__ () #9 0x94704075 in _pthread_start () #10 0x94703f32 in thread_start () Thread 7 (process 7956 thread 0x6e03): #0 0x946d38e6 in mach_msg_trap () #1 0x946db0dc in mach_msg () #2 0x969fe0fe in CFRunLoopRunSpecific () #3 0x969fed38 in CFRunLoopRunInMode () #4 0x954677ba in CFURLCacheWorkerThread () #5 0x94704075 in _pthread_start () #6 0x94703f32 in thread_start () Thread 6 (process 7956 thread 0x6d03): #0 0x946daace in __semwait_signal () #1 0x94705306 in _pthread_cond_wait () #2 0x94704ced in pthread_cond_wait$UNIX2003 () #3 0x92693460 in pthreadSemaphoreWait () #4 0x926a5d92 in CMMConvTask () #5 0x94704075 in _pthread_start () #6 0x94703f32 in thread_start () Thread 5 (process 7956 thread 0x6c03): #0 0x946daace in __semwait_signal () #1 0x94705306 in _pthread_cond_wait () #2 0x94704ced in pthread_cond_wait$UNIX2003 () #3 0x92693460 in pthreadSemaphoreWait () #4 0x926a5d92 in CMMConvTask () #5 0x94704075 in _pthread_start () #6 0x94703f32 in thread_start () Thread 4 (process 7956 thread 0x6b07): #0 0x946daace in __semwait_signal () #1 0x94705306 in _pthread_cond_wait () #2 0x94704ced in pthread_cond_wait$UNIX2003 () #3 0x92693460 in pthreadSemaphoreWait () #4 0x926a5d92 in CMMConvTask () #5 0x94704075 in _pthread_start () #6 0x94703f32 in thread_start () Thread 3 (process 7956 thread 0x6707): #0 0x94722f5a in select$DARWIN_EXTSN () #1 0x96a0954f in __CFSocketManager () #2 0x94704075 in _pthread_start () #3 0x94703f32 in thread_start () Thread 2 (process 7956 thread 0x5c03): #0 0x946d38e6 in mach_msg_trap () #1 0x946db0dc in mach_msg () #2 0x969fe0fe in CFRunLoopRunSpecific () #3 0x969fed38 in CFRunLoopRunInMode () #4 0x935e3560 in +[NSURLConnection(NSURLConnectionReallyInternal) _resourceLoadLoop:] () #5 0x9358004d in -[NSThread main] () #6 0x9357fbf4 in __NSThread__main__ () #7 0x94704075 in _pthread_start () #8 0x94703f32 in thread_start () Thread 1 (process 7956 thread 0x10b): #0 0x94709a36 in write$NOCANCEL$UNIX2003 () #1 0x9470998e in _swrite () #2 0x947098bb in __sflush () #3 0x946d4ac8 in __vfprintf () #4 0x94709603 in vfprintf_l () #5 0x94709597 in fprintf () #6 0x0007ef40 in BBDetailedLogWithVA (level=BB_LOG_INFO, lineNumber=56, fileName=0x856b0 "/Users/jon/Developer/BBUtilities/Src/BBDownloader.m", methodName=0x85610 "-[BBDownloader initWithURL:callBackObject:]", message=0x8c300, args=0xbfffd8b4 "?d\003\027????????") at /Users/jon/Developer/BBUtilities/Src/BBLogger.m:41 #7 0x0007efb5 in BBDetailedLog (level=BB_LOG_INFO, lineNumber=56, fileName=0x856b0 "/Users/jon/Developer/BBUtilities/Src/BBDownloader.m", methodName=0x85610 "-[BBDownloader initWithURL:callBackObject:]", message=0x8c300) at /Users/jon/Developer/BBUtilities/Src/BBLogger.m:51 #8 0x0006fdf5 in -[BBDownloader initWithURL:callBackObject:] (self=0x170364b0, _cmd=0x85be4, downloadURL=0x17036490, obj=0x17036200) at /Users/jon/Developer/BBUtilities/Src/BBDownloader.m:56 #9 0x0006fc3f in +[BBDownloader downloaderWithURL:callBackObject:] (self=0x8ec00, _cmd=0x85db8, downloadURL=0x17036490, obj=0x17036200) at /Users/jon/Developer/BBUtilities/Src/BBDownloader.m:32 #10 0x0006fbe3 in +[BBDownloader downloaderWithPath:callBackObject:] (self=0x8ec00, _cmd=0x24748, downloadPath=0x2d078, obj=0x17036200) at /Users/jon/Developer/BBUtilities/Src/BBDownloader.m:23 #11 0x000164bf in -[Scheduler startScheduler:] (self=0x17036200, _cmd=0x266c1, isLinked=1 '\001') at /Users/jon/Developer/MillicentPro/src/Scheduler.m:91 #12 0x0000fd49 in -[AppController startMainWindow] (self=0x136b20, _cmd=0x267d3) at /Users/jon/Developer/MillicentPro/src/AppController.m:222 #13 0x0000fa80 in -[AppController linkSucceeded] (self=0x136b20, _cmd=0x267c5) at /Users/jon/Developer/MillicentPro/src/AppController.m:193 #14 0x93580bfc in __NSThreadPerformPerform () #15 0x969fe64e in CFRunLoopRunSpecific () #16 0x969fed38 in CFRunLoopRunInMode () #17 0x928948a4 in RunCurrentEventLoopInMode () #18 0x928946bd in ReceiveNextEventCommon () #19 0x92894531 in BlockUntilNextEventMatchingListInMode () #20 0x96157d5b in _DPSNextEvent () #21 0x961576a0 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #22 0x961506d1 in -[NSApplication run] () #23 0x9611d9ba in NSApplicationMain () #24 0x0000246c in child_main (argc=1, argv=0xbfffe9b0) at /Users/jon/Developer/MillicentPro/src/main.m:23 #25 0x000024ce in main (argc=1, argv=0xbfffe9b0) at /Users/jon/Developer/MillicentPro/src/main.m:70 _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Socket (demand) based launchd daemons
by Perry Smith 23 Jan '08

23 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to:in-reply-to:content-type:mime-version:subject:date:references:x-mailer; bh=b7ULe5NtE8FB0+CzGSoF8kCjxTHfDntPRKykOwJEMA8=; b=nMwMC1qdoxvUsE9XAiLOdQrgRmi2TTNgQws0me/8+AaU4HIMBSd02pdFyuJp4Vf+ckz6YdYyZxtV9k173s0OwT2N8o0ElR9VTOxFOPQ08Tycg9X9LoXwlQg/HHJgNJKPGvRkwYyDwHdnbls6XNEWIYTwSxVc6Kuc45GYtm0KKk4= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:mime-version:subject:date:references:x-mailer; b=nfosMPo48WUpCP/3L9a0GtPHuQT27QCjXqqyETq1dXtrFKkJ6yrNIPnGRunynf+4QcfdAqt5rtL0JO4ZNPtebjZYBFRRunHKg3GvGREtFvJBRfzWRQ5++Ma0L9ddNSJwd5jEBU6SkDyToegqscMYhbLO5PRbhErqMlC+KsMY8Rg= ERROR: While executing gem ... (Errno::EADDRINUSE) Address already in use - bind(2) Which makes sense. launchd has the socket (port) open so the server can not bind to it. The server needs to at least have the ability to accept the fd rather than starting from scratch. I'm going to poke around in the server code and see what I can find. Thank you for the help, Perry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Socket (demand) based launchd daemons
by Dave Zarzycki 23 Jan '08

23 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com You can use wait == true then. http://trac.macosforge.org/projects/launchd/browser/trunk/launchd/doc/sampl… http://trac.macosforge.org/projects/launchd/browser/trunk/launchd/doc/sampl… davez On Jan 23, 2008, at 10:26 AM, Perry Smith wrote: Thanks. On Jan 23, 2008, at 10:57 AM, Dave Zarzycki wrote: <key>Sockets</key> <dict> <key>Listeners</key> <dict> <key>SockServiceName</key> <integer>12345</integer> </dict> </dict> <key>inetdCompatibility</key> <dict> <key>Wait</key> <false/> </dict> davez On Jan 23, 2008, at 8:17 AM, Perry Smith wrote: Thank you, Perry Smith _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/zarzycki%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… However, if you really want to go down this route, please review the 'sampled' project: I saw that but was afraid it would respawn the server with each http request. The socket will be used only briefly but the server is going to keep running. Really... this piece of code isn't set up to be launched in this manner. Maybe I should just keep what I have and launch it at boot time and be happy. But, if I continue on: I'm looking at launch.h and reading. I was toying with an idea of writing a program, call it "get_sockets". The script would run get_sockets and get_sockets would print on stdout something that could be easily parsed. Like the key for each socket and then the fd number for that key. I'm making great leaps of assumptions here on what the launch_data is going to look like so I may be way off base. Given that you're using a scripting language, your best option is to leverage launchd's inetd compatibility. By doing so, you'll get automatic concurrency (at the cost of inefficiency) and implicit compatibility with other operating systems that supply [x]inetd. Assuming that your program is TCP based, then this should be sufficient: Once you make that change, you'll find the socket on stdin/stdout/ stderr at launch. This question has come up for me before and I suspect it will again. The example this time is the web "server" that serves the Ruby "rdoc" documentation. You start it with "gem server". It has a few options like which port which has a default. I have a launchd plist file that simply starts this up at boot. But, mostly so I can show off to my friends (if I had any :-), I'd like to start it up the first time I browse to that port. The man page for launchd.plist says that the process has to "check in" using the launch(3) API. "man 3 launch" gives me back nothing. So I am lost as to what API's there are. But, even if I could find them, thats really just half the problem. The real problem is I'm looking for a way to transfer the file descriptor from launchd to the gem server using a script. (I can't modify gem just to do this -- well, I suppose I could but that only defers the problem until next time this comes up). So, how is this done? Or... if I need to write some code, thats fine. But, where do I start? This email sent to zarzycki(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0