Maybe he's referring to the case where libc.so doesn't have
the epoll bindings, but the underlying kernel does?
Oh yes, I bet that's it. I never really thought about that before but I
guess there's no reason why libc would always support every feature of
the kernel. Thanks Dan!
Mike Hearn wrote:
That's fine, except that compiling your library on a machine that has
epoll, and then trying to run it on a machine without will not work.
It will not load if runtime glibc doesn't have epoll. I'm using
"syscall" to work around that problem in wine.
Why not use dlopen?
Maybe h
That's fine, except that compiling your library on a machine that has
epoll, and then trying to run it on a machine without will not work. It
will not load if runtime glibc doesn't have epoll. I'm using "syscall"
to work around that problem in wine.
Why not use dlopen?
Dan Kegel wrote:
Shachar Shemesh wrote:
Now don't go and do level-triggered stuff just because it's easier :-)
That's not it at all, and edge vs. level is not part of my
considerations. Libevent does support a wider variety of selection
interfaces, and with wider platform support, than your libra
Shachar Shemesh wrote:
Now don't go and do level-triggered stuff just because it's easier :-)
That's not it at all, and edge vs. level is not part of my
considerations. Libevent does support a wider variety of selection
interfaces, and with wider platform support, than your library.
Don't get me
Dan Kegel wrote:
Shachar Shemesh wrote:
It doesn't compile (rn.c is not including ). When I fix
that, it checks whether epoll_create works. If it does, it sets all
handlers to use sigio. I don't think this library is quite stable
enough :-)
You're a tough customer :-) It's quite close; guess I
Shachar Shemesh wrote:
It doesn't compile (rn.c is not including ). When I fix
that, it checks whether epoll_create works. If it does, it sets all
handlers to use sigio. I don't think this library is quite stable enough
:-)
You're a tough customer :-) It's quite close; guess I should polish it
Shachar Shemesh wrote:
Dan Kegel wrote:
By all means, let's try epoll.
FWIW, I wrote a wrapper layer that illustrates how to detect
whether epoll etc. are available. I'm convinced that *runtime*
detection is the only way to go.
That's fine, except that compiling your library on a machine that has
Shachar Shemesh wrote:
FWIW, I wrote a wrapper layer that illustrates how to detect
whether epoll etc. are available. I'm convinced that *runtime*
detection is the only way to go. Compile time detection is insufficient.
My code is at http://kegel.com/rn
Sure will have a look.
cool!
i
If you actua
Dan Kegel wrote:
Shachar wrote:
I noticed that in server/fd.c, the wineserver is using "poll" to
select between file descriptors. The application is going through
this code over 2000 times a second, with over 380 file descriptors
each time. I am wondering whether this can be the cause of the slo
Shachar wrote:
I noticed that in server/fd.c, the wineserver is using "poll" to select
between file descriptors. The application is going through this code
over 2000 times a second, with over 380 file descriptors each time. I am
wondering whether this can be the cause of the slowdown.
One of th
On Thu, 19 Aug 2004 22:16:36 +0300, Shachar Shemesh wrote:
> One last question. What are the "users"? What constructs cause a new
> file descriptor to be allocated in the wineserver?
Every thread in every client has 3 fds: command, reply, wait. Other fds
are allocated as well I think for things l
Hi all,
I have a program (a server) that has a very large number of
synchronization constructs. Even when everything is idle there,
wineserver is taking 60% of the CPU, raising load average to 2.4. When
load is applied, response time occasionally jumps from tenths of a
second to two minutes.
I
13 matches
Mail list logo