Dear Benny,
Firstly, Thanks to your help. My linux kernel is 2.6.18. About changing
the ioqueue implementation to ioqueue_epoll, I modify the build.mak and
build the pjproject again. But it still uses the ioqueue_select.c. Which
step does I miss?
Simon
----- Original Message -----
From: "Benny Prijono" <bennylp@xxxxxxxxx>
To: "pjsip list" <pjsip at lists.pjsip.org>
Sent: Thursday, June 05, 2008 5:39 PM
Subject: Re: pj_thread_sleep(0) problem in linux platform issue
> On Thu, Jun 5, 2008 at 9:26 AM, Simon Chen <simonmychen at seed.net.tw>
> wrote:
>> Dear Benny,
>>
>> I have tried the sleep(0) solution. Task-switch will not occure when
>> the sleep(0) is called. Is there any other suggestion?
>>
>
> Just for reference, which linux kernel version is that?
> IMO, you shouldn't rely on pj_thread_sleep(0) to switch thread, since
> as you experience, it's not portable across platforms. Use explicit
> sched_yield() for that and Sleep(0) on Windows. Of course the ideal
> solution is to avoid this altogether by refactoring the application.
>
>> Any issue is about the bad TCP throughput. At Linux platform,
>> ioqueue_select performance is really not good. The TCP throughput is half
>> than using blocking socket directly. I have replaced ioqueue_select by
>> ioqueue_epoll.c. Its performance is good. But I don't know how to
>> configure
>> makefile corrrectly for linux to use the ioqueue_epoll.c. Now, I use a
>> stupid method that modify directly the ioqueue_epoll.c filename to
>> ioqueue_select.c. Can you tell me how to configure it? Thanks!
>>
>
> You can modify this line in build.mak:
> export LINUX_POLL := select
> to
> export LINUX_POLL := epoll
>
> Mind you ioqueue_epoll has not been tested very extensively.
>
> Cheers
> Benny
>
>
>> Simon
>>
>>
>> ----- Original Message -----
>> From: "Benny Prijono" <bennylp@xxxxxxxxx>
>> To: "pjsip list" <pjsip at lists.pjsip.org>
>> Sent: Thursday, May 22, 2008 5:50 PM
>> Subject: Re: pj_thread_sleep(0) problem in linux platform issue
>>
>>
>>> On Thu, May 22, 2008 at 5:07 AM, Simon Chen <simonmychen at seed.net.tw>
>>> wrote:
>>>> Hi! Benny,
>>>>
>>>> Sorry! I forgot describe my application firstly.
>>>> I use pjlib to implement a proprietary TCP serve-client application
>>>> for
>>>> cross-platform issue. I got a problem when I use mutex lock and unlock
>>>> to
>>>> protect the channel object. Two thread(A, B) will access the channel
>>>> object
>>>> at the same time. Before channel object is accessed, lock the mutex and
>>>> unlock it after finished access. Thread A always loops to access the
>>>> channel
>>>> object. Thread B sometimes access the it. In windows platform, it can
>>>> work
>>>> perfectly. But in linux platform, Thread B can't access the channel
>>>> object.
>>>> I add the pj_thread_sleep(0) between mutex unlock and lock to force
>>>> task
>>>> switch. Then Thread B can sccess it. But this will cause the Thread A
>>>> to
>>>> sleep 10 ms every loop in linux platform (in windows,
>>>> pj_thread_sleep(0)
>>>> just forces task switch and don't sleep) This will cause my application
>>>> performance bad.
>>>>
>>>
>>> I have a feeling that something is not right there (I mean, one thread
>>> running on a busy loop doesn't sound like very efficient), but I don't
>>> want to criticize that. I'm just glad to hear that the problem is not
>>> in pjsip code. ;-)
>>>
>>>> I agree your statement "considering that application may create
>>>> threads
>>>> with different priorities and also the process itself may be set to
>>>> particular scheduling policy, it may not achieve what we want", but I
>>>> think
>>>> pj_thread_sleep(0) should be just forced to task switch. If wanna avoid
>>>> the
>>>> different thread priorities or scheduling situation, using
>>>> pj_thread_sleep(n) may be more suitable. So I advance my suggestion. Is
>>>> it
>>>> reasonable? Hope to hear your advice. Thanks!
>>>>
>>>
>>> Hmm.. actually from this: http://skyos.org/bugs/view.php?id=1972, it
>>> looks like usleep(0) and nanosleep(0) behaves differently than
>>> sleep(0), and it may be that sleep(0) will fit with what you want.
>>>
>>> What if you replace sched_yield() to sleep(0) for pj_thread_sleep(0)
>>> case in your patch? Does it work as expected?
>>>
>>> If so, then your patch will be more acceptable and we can defer
>>> sched_yield() discussion to another day. :)
>>>
>>> Cheers
>>> Benny
>>>
>>> _______________________________________________
>>> Visit our blog: http://blog.pjsip.org
>>>
>>> pjsip mailing list
>>> pjsip at lists.pjsip.org
>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>
>>
>>
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> pjsip at lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
