You will likely queue the data up; think about how you’re going to be getting the data … it’s spooling in at a rate X, at that point you either read it at rate Y or queue it. If you’re doing this from a shared memory segment then the “reader” thread is at PASV, subject to being swapped out as soon as a higher priority thread/ APC/ DPC/ ISR comes along … and you’ll stay swapped out for micro or milliseconds, tenths of seconds or days depending on how the higher priority thread was written. Meanwhile, your data continues to spool in at rate X …
If you queue it, then where would you rather gather the data … at PASV, where your thread will be go away everytime SilverLight decides to run (thanks, MS, for dynamically increasing thread priority *just because*!) or similar, or at SYSTEM, where only APC’s, DPC’s and ISR’s can trump you …
Also, how do you “know” when something new has come in? Well, you could poll a location/ pointer, but see above – your polling will get swapped out everytime the multimedia player is run. It’s also very inefficient – you’re tying up a core just reading a location endlessly, mindlessly. Wouldn’t it make more sense to get somehow notified that some new data is available?
So, here’s what I would suggest: queue up your data in one of N buffers of M size using a thread, DPC, etc. and have this data accumulate. In usermode create a thread who simply posts an IOCTL (overlapped) and passes in a buffer of M size … and waits. When the thread gathers the data you want it copies the N’th buffer data into the IOCTL buffer, completes it and starts writing data to the next buffer … and repeat …
Using this approach you a) don’t ever lose data, as it’s being cached in a nice, safe driver buffer by something operating above the level of Silverlight, b) are notified when something has come in and can pull the data when your usermode app is ready to work with the data and c) have a much lower impact on overall performance than something polling … that, as many others have stated, is the essence of the inverted call …
You can get much, much fancier of course: hi/lo watermarks on the buffers for completion, completion ports on the user thread for even better performance, backpressure through the IOCTL, etc. etc. but that’s the jist of it. As Don has mentioned there *are* some cases where shared memory segments are the right solution but the design you mention is almost a perfect fit for an inverted call approach …
Cheers!