Mike McCormack <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> A few more changes after consulting with Alexandre.
>
> ChangeLog:
> * add epoll implementation to libwine_port
:
> +__asm__ __volatile__( "pushl %%ebx; movl %2,%%ebx; int $0x80; popl
> %%ebx" +
Mike McCormack wrote:
But first I'd like to try and get this more simple improvement
accepted into the CVS.
Amen
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 alre
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 er
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 t
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
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 conf
