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: "Jonathan del Strother" <email@hidden>
- Date: Thu, 24 Jan 2008 15:59:35 +0000
On Jan 24, 2008 1:42 PM, Jonathan del Strother <email@hidden> wrote:
> On Jan 24, 2008 1:12 PM, Terry Lambert <email@hidden> wrote:
> > 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.
> >
>
> I'm only logging a few lines - maybe 500 characters in total - so I
> can't see how I'd be overloading the queue. Even if I did, presumably
> the write() call ought to return eventually?
>
> I haven't yet been able to reproduce this outside of Xcode - it's
> tempting to blame it on an oddity in Xcode's run log and forget about
> it...
*Finally* found the problem, and am feeling dumb for not spotting the
pattern before.
Obviously it was nothing to do with fprintf and/or threads. In
certain conditions, my application relaunches itself. When it does
so, the new process would manage a few log messages, then the original
process would quit, and the new process would block the next time it
tried to write to stderr.
So, I assume that the file handles created for the original process
are getting inherited through to the new process, but not surviving
once the old process exits. Looks like I need to find a better way of
relaunching...
Thanks for all the help and suggestions,
Jon
_______________________________________________
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