> 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?
I use the " OS_NAME := auto " in build.mak. Should I modify to "export
OS_NAME := linux" ?
>
> 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
>>
>
>
>
> _______________________________________________
> 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
>
