[Live-devel] Design choice
Tim Zaitsev
tim at rabbit.tv
Fri Jul 27 15:22:11 PDT 2012
Ross,
This is fascinating but I can't picture it. What would the design look
like for multiple processes (one per stream as you describe)?
Are there any examples of this that I can take a look at?
Thanks,
Tim
On Fri, Jul 27, 2012 at 1:23 PM, Ross Finlayson <finlayson at live555.com>wrote:
> When implementing liveMedia using multiple streams in one process I see two
> choices:
>
> 1. Each stream is kept totally separate. I.e. each stream have their own
> TaskScheduler, UsageEnvironment, eventLoopWatchVariable and each
> doEventLoop() is running in a separate thread.
>
> 2. The rtspClient's share the same TaskScheduler, UsageEnvironment,
> eventLoopWatchVariable and there is one doEventLoop() running (as in the
> testRTSPClient project).
>
>
> Correct. Those are the only two choices, *if* you have also chosen to use
> just one process. (Note below.)
>
>
> I've current implemented design 1, while I see option 2 being the intended
> choice. The reason for picking 1 is the added "security" of keeping each
> stream entirely independent, i.e. if an exception occurs for any reason
> only
> one stream should be affected.
>
>
> Well, it depends on what you mean by "exception". If one thread has a
> memory access error, then it will kill the entire process. And there's
> nothing to prevent one thread (due to a bug somewhere) from stepping all
> over memory that's used by another thread. So there's really not much
> 'security' here at all.
>
> If your streams really are "entirely independent", then why not use one
> process for each stream? That is by far the safest and most reliable
> approach.
>
> But for some odd reason, here in the 21st century, the idea of structuring
> an application as multiple processes seems to have fallen our of favor...
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120727/f0efc350/attachment.html>
More information about the live-devel
mailing list