• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Crash in CFReadStreamOpen
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Crash in CFReadStreamOpen


  • Subject: Re: Crash in CFReadStreamOpen
  • From: Benoit Foucher <email@hidden>
  • Date: Fri, 29 May 2009 14:29:40 +0200

Hi,

On May 29, 2009, at 11:56 AM, Quinn wrote:
I'm not saying that you can't do cross thread source scheduling and unscheduling. What I'm saying is that this is not a well-trodden path, and if there are bugs in the system you're likely to be the one finding them. Personally, that's not the way I like to travel.

If you do find specific, reproducible problems with this, feel free to file a bug about them.

<http://developer.apple.com/bugreporter/>

Ok, I'll submit a report.

The way I usually do this is... well, I usually try to keep everything running on the main thread. Unless you have an extremely performance sensitive application this is usually good enough. One step up in complexity is to put all of the I/O (as opposed to GUI or CPU) operations on one thread. This will help with performance because I/O operations won't be block by the high latency GUI or CPU- bound operations. Finally, once I've shown that it's worth the effort, I'd consider a move to a multi-runloop design.

Within my multi-runloop design I would put each source on just one runloop. That each, each thread in my pool would be responsible some some set of sources, and sources wouldn't move between threads. You can then have each thread listen for new work, create the sources associated with that work, and schedule those sources on its own runloop.

I'm working on a multi-platform software that uses a thread pool for IO and message dispatching (using the leader/follower pattern with epoll, kqueue or select depending on the OS). Using another design isn't really an option for me as I want to minimize the changes (I need to support CFStream socket transports for SSL). Anyway, I think I have a solution. I'm adding a run loop source dedicated to the scheduling of new streams. When I need to add a new stream to the run loop, I put the stream in a queue and signal this source to get the runloop thread to schedule it.


Thank you all for your help.

Cheers,
Benoit.



S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/ >
Apple Developer Relations, Developer Technical Support, Core OS/ Hardware
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

_______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Follow-Ups:
    • Re: Crash in CFReadStreamOpen
      • From: Jens Alfke <email@hidden>
References: 
 >Crash in CFReadStreamOpen (From: Benoit Foucher <email@hidden>)
 >Re: Crash in CFReadStreamOpen (From: Jens Alfke <email@hidden>)
 >Re: Crash in CFReadStreamOpen (From: Benoit Foucher <email@hidden>)
 >Re: Crash in CFReadStreamOpen (From: Quinn <email@hidden>)

  • Prev by Date: Re: Crash in CFReadStreamOpen
  • Next by Date: Re: Crash in CFReadStreamOpen
  • Previous by thread: Re: Crash in CFReadStreamOpen
  • Next by thread: Re: Crash in CFReadStreamOpen
  • Index(es):
    • Date
    • Thread