Davide Libenzi wrote:
There is no known problem in using epoll_ctl() in one thread while
another does epoll_wait().
I suggest you to ask Valgrind to take a look at you binary. Since I
have no clue of what your software does, please create the *minimal*
code snippet that exploit the eventual
On Tue, 23 Aug 2005, Davy Durham wrote:
Davide Libenzi wrote:
I should mention that the 2.4 patch is old WRT mainline epoll in 2.6 (I
stopped maintaining it when 2.6 went "stable"). I'd definitely suggest to
use 2.6 if you are looking at epoll.
I am using linux-2.6.11 and glibc-2.3.4 ..
Jari Sundell wrote:
On 8/23/05, Davy Durham <[EMAIL PROTECTED]> wrote:
I was hoping you would mention in your reply that you knew
epoll_data_t was an union and you didn't touch epoll_data::fd, so i
wouldn't have to say it explicitly. ;)
Oh!.. unless the epoll_data_t is a union just for
Jari Sundell wrote:
On 8/23/05, Davy Durham <[EMAIL PROTECTED]> wrote:
I was hoping you would mention in your reply that you knew
epoll_data_t was an union and you didn't touch epoll_data::fd, so i
wouldn't have to say it explicitly. ;)
No, I saw that epoll_data_t was a union (although,
Davide Libenzi wrote:
I should mention that the 2.4 patch is old WRT mainline epoll in 2.6
(I stopped maintaining it when 2.6 went "stable"). I'd definitely
suggest to use 2.6 if you are looking at epoll.
I am using linux-2.6.11 and glibc-2.3.4 .. and using select() in it's
place seems to
On Tue, 23 Aug 2005, Willy Tarreau wrote:
On Tue, Aug 23, 2005 at 06:55:26AM -0500, Davy Durham wrote:
Thanks for the info.. I did find this thread and was wondering if this
patch ever got put in
http://www.ussg.iu.edu/hypermail/linux/kernel/0303.3/1139.html
Interesting ! At least it does n
On 8/23/05, Davy Durham <[EMAIL PROTECTED]> wrote:
> Yes, that is what I was thinking and is why I mentioned that. But I'm
> apparently not overwriting the pointers with FDs.. it seems that epoll
> is the cause at this point (unless I'm misusing the epoll API). I've
> made some changes to now us
On Tue, Aug 23, 2005 at 06:55:26AM -0500, Davy Durham wrote:
> Thanks for the info.. I did find this thread and was wondering if this
> patch ever got put in
>
> http://www.ussg.iu.edu/hypermail/linux/kernel/0303.3/1139.html
>
Interesting ! At least it does not seem to be present in the
epoll-2
Thanks for the info.. I did find this thread and was wondering if this
patch ever got put in
http://www.ussg.iu.edu/hypermail/linux/kernel/0303.3/1139.html
Willy Tarreau wrote:
On Tue, Aug 23, 2005 at 06:24:42AM -0500, Davy Durham wrote:
That's probably a good idea. Where would I find o
Jari Sundell wrote:
On 8/23/05, Davy Durham <[EMAIL PROTECTED]> wrote:
However, I'm getting segfaults because some pointers in places are
getting set to low integer values (which didn't used to have those values).
Is it possible that you are overwritting the pointers with file
descrip
On Tue, Aug 23, 2005 at 06:24:42AM -0500, Davy Durham wrote:
> That's probably a good idea. Where would I find out what other projects
> use it?
I use it in my load-balancer (haproxy), and it could somewhat match your
needs, because I ported the select()-based earlier version to epoll() with
the
On 8/23/05, Davy Durham <[EMAIL PROTECTED]> wrote:
>
> However, I'm getting segfaults because some pointers in places are
> getting set to low integer values (which didn't used to have those values).
Is it possible that you are overwritting the pointers with file
descriptors, as those would have
That's probably a good idea. Where would I find out what other projects
use it?
Willy Tarreau wrote:
Hi,
On Tue, Aug 23, 2005 at 06:01:15AM -0500, Davy Durham wrote:
I just mean that when I debug and catch the segv, it's dies because
some pointers now have corrupted values. (usually be
Davy Durham wrote:
I'm currently re-writing some code to make it use select() instead of
epoll_wait() and see if everything is suddently fixed. If so, then I
will suspect that epoll has a problem. But it's still not ruled out
being my fault since it could be a timing issue that makes the c
Hi,
On Tue, Aug 23, 2005 at 06:01:15AM -0500, Davy Durham wrote:
> I just mean that when I debug and catch the segv, it's dies because
> some pointers now have corrupted values. (usually because something is
> overwriting some memory some where)
>
> I'm currently re-writing some code to make
bert hubert wrote:
On Tue, Aug 23, 2005 at 04:49:14AM -0500, Davy Durham wrote:
However, I'm getting segfaults because some pointers in places are
getting set to low integer values (which didn't used to have those values).
epoll is pretty heavily benchmarked and hence tested. I don't
On Tue, Aug 23, 2005 at 04:49:14AM -0500, Davy Durham wrote:
> However, I'm getting segfaults because some pointers in places are
> getting set to low integer values (which didn't used to have those values).
epoll is pretty heavily benchmarked and hence tested. I don't entirely
understand the re
So, I've been trying to use epoll.. on linux-2.6.11-6mdk
However, I'm getting segfaults because some pointers in places are
getting set to low integer values (which didn't used to have those values).
The deal is that my application is multi-threaded, and I was wondering
if epoll had issues i
18 matches
Mail list logo
