libc_r is deprecated

[David Xu]

Marc Olzheim wrote:

>>libc_r runs on single kernel thread, so if you are continue using libc_r,
>>you are not testing TCP/IP with multithreads program, this may give you
>>false data. Only kernel threads based server can test to see if the TCP/IP
>>stack locking works well.
>>    
>>
>
>Erhm, its not about testing the TCP/IP stack locking, this is about
>stable and raw performance. Of course the single kernel thread might
>have a negative impact on total performance, but in our real world
>applications, I don't see a real performance boost from KSE.
>
>What I do see is easier and cleaner programming with KSE, but once
>you've done all the work to get usable libc_r based I/O, it works good.
>(Well, unless you need to fork+exec from a heavily mallocing thread
>system, without a patch similar to the one in PR threads/76690...)
>
>Marc
>  
>
What is raw performance? are you comparing it with RELENG-4, if you only
need a single thread, why should we start SMP project ? I am interesting 
to see
libthr is worse than libc_r in real world application, give us example.
I have an example,  run Dave's crew example from his book, libc_r just 
falls on
its face. http://people.freebsd.org/~davidxu/ptest.tgz
also, Robert can get better result if he does not use libc_r but use a 
state machine
but not thread to serve http request like an example in ACE.

David Xu