Re: add epoll implementation to libwine_port (take 3)
Mike McCormack wrote:
ChangeLog: * add epoll implementation to libwine_port
....
+ __asm__ __volatile__( "pushl %%ebx; movl %2,%%ebx; int $0x80; popl %%ebx"
Grate ! [Q] Does that mean that we directly check if it is supported in kernel, bypassing glibc all together? how do we avoid conflicts with glibc?
Boaz Harrosh wrote:
[Q] Does that mean that we directly check if it is supported in kernel, bypassing glibc all together? how do we avoid conflicts with glibc?
The definitions are wrapped by #ifndef HAVE_EPOLL_CREATE, which is set by a configure check. The end result is that we use this code if libc does not provide an epoll implementation, and use libc's if it is available. Mike
Mike McCormack wrote:
Boaz Harrosh wrote:
[Q] Does that mean that we directly check if it is supported in kernel, bypassing glibc all together? how do we avoid conflicts with glibc?
The definitions are wrapped by #ifndef HAVE_EPOLL_CREATE, which is set by a configure check.
The end result is that we use this code if libc does not provide an epoll implementation, and use libc's if it is available.
Mike
You do realize that many (somewhat old) glibcs have epoll_create defined that is hardwired to return E_NOSYS without calling the kernel, right? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Shachar Shemesh wrote:
You do realize that many (somewhat old) glibcs have epoll_create defined that is hardwired to return E_NOSYS without calling the kernel, right?
It won't do any worse than the code that is already there now, as we fall through to the select code if epoll_create returns an error. In the case of glibc that are missing epoll functions (like mine 2.3.2) it will do better. We could try to fall back to the syscall method if the glibc implementation returns an error, but first I'd like to try and get this more simple improvement accepted into the CVS. Mike
On Wed, Oct 20, 2004 at 02:32:53AM +0900, Mike McCormack wrote:
Shachar Shemesh wrote:
You do realize that many (somewhat old) glibcs have epoll_create defined that is hardwired to return E_NOSYS without calling the kernel, right?
It won't do any worse than the code that is already there now, as we fall through to the select code if epoll_create returns an error.
In the case of glibc that are missing epoll functions (like mine 2.3.2) it will do better.
We could try to fall back to the syscall method if the glibc implementation returns an error, but first I'd like to try and get this more simple improvement accepted into the CVS.
The glibc method should have preference, and we should of course check for ENOSYS. We should assume that glibc does it right in the long run. (Any deployment scenario is most likely starting in years instead of right now.) So glibc use first, handhacked assembler then. Ciao, Marcus
participants (4)
-
Boaz Harrosh -
Marcus Meissner -
Mike McCormack -
Shachar Shemesh