Re: NSFileHandle readInBackground vs threading?
Re: NSFileHandle readInBackground vs threading?
- Subject: Re: NSFileHandle readInBackground vs threading?
- From: Don Quixote de la Mancha <email@hidden>
- Date: Wed, 09 Nov 2011 00:27:20 -0800
Keep pointers to your packetBuffers in a circular buffer. When a new
packet comes in, add it to the front of the buffer. When you're ready
to process a packet, remove it from the end of the buffer.
Some testing should determine how big your buffer needs to be.
On anything but a real-time operating system, your entire process is
going to spend some time totally halted. Incoming data will build up
either in the kernel's buffers on your local machine, or the sending
process will be unable to send data. If you're using UNIX domain
sockets or TCP, the sending process will block. If you're using UDP
or some other non-guaranteed-delivery protocol, your data will be
dropped on the floor.
If you're not familiar with circular buffers, you can keep your
packetBuffer pointers in some kind of array. Keeping them in an
NSArray will enable them all to be released when the NSArray itself is
released.
You need two indices, called say "head" and "tail". head contains the
index of the next free packetBuffer. Increment it when a packetBuffer
has been used, but when you get to the end of the array, set it to
zero. tail will point to the last packetBuffer that contains valid
data.
Your queue is full when the head comes back around to be one element
behind the tail, so that incrementing the head will make it equal to
the tail. At that point you really do need to block, or alternatively
keep reading packets but then dropping them on the receiving end.
A while back I wrote a very fast circular buffer for audio data that
is thread-safe. It blocks the sending thread when it gets full, and
feeds silence to the output thread when the buffer is empty.
Alternatively simple change would enable the output thread to block
when the buffer is empty.
It doesn't *look* thread-safe but I am quite certain that it really is:
http://www.oggfrog.com/free-music-software/source-code/
It is a C++ class called ZPCMQueue. It depends on the ZooLib C++
cross-platform application framework, but it only really uses ZooLib's
platform-independent atomic arithmetic and thread synchronization
primitives. It would be very easy to replace those with Cocoa's.
I'm pretty sure that part of Ogg Frog's code is published under the MIT License.
--
Don Quixote de la Mancha
Dulcinea Technologies Corporation
Software of Elegance and Beauty
http://www.dulcineatech.com
email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden