[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