how to limit the thread number?

[Dan Kegel]

I think gstreamer 0.8 did have a way to avoid using threads,
called cothreads; it seems to have been removed by this commit:
http://marc.info/?l=gstreamer-cvs&m=111737515027392&w=2
Don't know why, but I do know simulating threading is a pain,
maybe it didn't work too well.

Why is your centos box limited to 300 threads?



On Fri, Jul 25, 2014 at 1:59 AM, Wang Zhenzhong <wangzz at avonaco.com> wrote:
> thank you very much
> I know what's your mean.
>
> let's calc it:
> the centos of our server will be limited about 300 thread (optimized by
> ulimited and etc)
> and one user of our app will be created 5 thread in gstreamer,
> so our capacity is about 60 users,  and our app is peer-call,
> so our server which is using gstreamer is only support 30 calls maxly
>
> then, we discuss:
> 1. gstreamer is a very beautiful framework,  so if it design for server next
> step, I think it must be more beautiful
> 2. whatever for client or server,  the thread num which is related with
> element is a ugly idea
> 3.  is there any roadmap of gstreamer to support confirmed thread num
>
>
>
> ________________________________
>
> 王振中
>
>
>
>
> From: Edward Hervey
> Date: 2014-07-25 15:07
> To: wangzz; Discussion of the development of and with GStreamer
> Subject: Re: how to limit the thread number?
> Hi,
>
>
> On Fri, 2014-07-25 at 09:58 +0800, Wang Zhenzhong wrote:
>> Hi:
>> every body,  we are using gstreamer for develop media server.
>> the media server need support many audio/video user,
>> so every user include udpsrc/rtpsrc/decode/encode/rtpsink/udpsink...
>> must create about 3-5 threads
>
>   That sounds about right
>
>> but the centos's thread num and memory is limited, so the capability
>> of our server is limited by gstreamer's thread number
>
>   Have you investigated changing those limits ? via ulimit/getrlimit.
>
>>
>> is there anyway to limit the thread num of gstreamer? such as
>> confirmed thread num in startup and unrelated to user num
>
>   GStreamer is multi-threaded, it *needs* those (streaming) threads to
> work. If a thread can't be created, it will fail. What you can do
> though, is figure out how many threads will be created.
>
>   The rule of thumb is (roughly):
>   * queue element will create one new streaming thread
>   * sources (when working push-based, such as udpsrc) or demuxers (when
> working pull-based) will create one new streaming thread
>   * Some other elements might create a streaming thread (such as the
> jitterbuffer normally used in client-side RTP pipelines).
>
>   If you're not sure, create one pipeline (I'm assuming your pipelines
> are identical), and look at how many threads are running (top, and then
> 'H' to view each thread is quite useful for that). Take your thread
> limits, divide it by that => you have your maximum number of clients you
> can accept. But once again, you should check whether you can change the
> limit of threads via ulimit/getrlimit first.
>
>    Regards,
>
>      Edward
>
>>
>> thankyou
>>
>>
>>
>> ______________________________________________________________________
>>
>> 王振中
>>
>>
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>