On Wed, Jan 09, 2013 at 11:22:43AM -0600, Mark Ellzey wrote:
> On Tue, Jan 08, 2013 at 11:29:01PM +0100, Bj?rn K. wrote:
> > This is the valgrind --tool=helgrind output. The first part appears
> > for every connection to the server:
> -- cut --
>
OK, you need to add a mutex around anything that
On Tue, Jan 08, 2013 at 11:29:01PM +0100, Bj?rn K. wrote:
> This is the valgrind --tool=helgrind output. The first part appears
> for every connection to the server:
-- cut --
Yikes, I will dig into this.
***
To unsubscribe, se
I misunderstood the way how your code works. After rereading it, I
think I will use it in my program. Thanks.
2013/1/8 Mark Ellzey :
> On Tue, Jan 08, 2013 at 11:30:00AM +0100, Bj?rn K. wrote:
>> The posted code compiles on my machine without modifications. Thus I
>> wonder why you have to do some
This is the valgrind --tool=helgrind output. The first part appears
for every connection to the server:
==5477== Possible data race during write of size 4 at 0x602707c by thread #1
==5477==at 0x412DFC: bufferevent_incref_and_lock_ (bufferevent.c:653)
==5477==by 0x412E4F: bufferevent_enable
On Mon, Jan 07, 2013 at 11:55:04PM +0100, Bj?rn K. wrote:
> That piece of code should distribute the incoming connections over the
> threads (I want to change that code later to select the thread with
> the lowest number of handled connections). If I don't use this code
> and use instead
> bev = bu
On Tue, Jan 08, 2013 at 11:30:00AM +0100, Bj?rn K. wrote:
> The posted code compiles on my machine without modifications. Thus I
> wonder why you have to do some cleanup.
> But the example code fails silently. Perhaps you don't run it with
> enough rights to bind to port 443?
>
> Most of the time
On Tue, Jan 8, 2013 at 12:30 PM, Björn K. wrote:
> The posted code compiles on my machine without modifications. Thus I
> wonder why you have to do some cleanup.
>
Maybe because I run with older system (10.6).
> But the example code fails silently. Perhaps you don't run it with
> enough rights
Hey Björn,
multithreading and libevent is a bit tricky (at least it was for me). I
would also suggest to change your design...
I developed a multithreaded websocket server based on libevent a year ago:
My approach was to create a single event base per thread. Each event base
in each thread listen
Hey Björn,
multithreading and libevent is a bit tricky (at least it was for me). I
would also suggest to change your design...
I developed a multithreaded websocket server based on libevent a year ago:
My approach was to create a single event base per thread. Each event base
in each thread listen
The posted code compiles on my machine without modifications. Thus I
wonder why you have to do some cleanup.
But the example code fails silently. Perhaps you don't run it with
enough rights to bind to port 443?
Most of the time I access the server with a browser and keep the
reload button pressed.
On Jan 8, 2013, at 12:55 AM, Björn K. wrote:
> That piece of code should distribute the incoming connections over the
> threads (I want to change that code later to select the thread with
> the lowest number of handled connections). If I don't use this code
> and use instead
> bev = bufferevent_o
That piece of code should distribute the incoming connections over the
threads (I want to change that code later to select the thread with
the lowest number of handled connections). If I don't use this code
and use instead
bev = bufferevent_openssl_socket_new(thread_base[0], sock, client_ctx, ...
t
On Sun, Jan 06, 2013 at 09:39:48PM +0100, Bj?rn K. wrote:
at a second glance:
next_thread = (next_thread + 1) % NUM_THREADS; <- are you sure this is
working as intended?
***
To unsubscribe, send an e-mail to majord...@freehaven.
On Sun, Jan 06, 2013 at 09:39:48PM +0100, Bj?rn K. wrote:
> Using valgrind I got the following report (I couldn't produce a
> segmentation fault):
>
> ==25006== Warning: invalid file descriptor 1019 in syscall accept()
> [warn] Error from accept() call: Too many open files
>
> The memory leaks ar
Using valgrind I got the following report (I couldn't produce a
segmentation fault):
login@adrastea-debian:~/test$ sudo valgrind ./simple==24900==
Memcheck, a memory error detector
==24900== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==24900== Using Valgrind-3.6.0.SVN-Debian a
Given that you have debian, why don't you install valgrind and see what
it says when you run the test?
***
To unsubscribe, send an e-mail to majord...@freehaven.net with
unsubscribe libevent-usersin the body.
I now tried setting up locking callbacks. But my programm still
crashes while stress testing.
I've attached the current code and a stack trace from gdb.
I don't know if it's an openssl or libevent related problem, but I
think I set the locking functions up correctly.
Regards
Björn
/* Program rec
On Tue, Dec 18, 2012 at 12:53:11AM +0100, Bj?rn K. wrote:
> I tried to simplify my code as much as possible. You can see the
> simplified code and the error message from gdb below.
> Every thread has its own event_base. The only access to the
> event_bases of the threads is from the event_base_loop
I tried to simplify my code as much as possible. You can see the
simplified code and the error message from gdb below.
Every thread has its own event_base. The only access to the
event_bases of the threads is from the event_base_loop of the
corresponding thread and the bufferevent functions in acce
On Sun, Dec 16, 2012 at 10:52 AM, Björn K. wrote:
> Hello,
>
> I'm trying to write a simple https server which utilizes multiple cpu cores.
> I call evthread_use_pthreads() and create several pthreads
I can't tell without looking at the rest of the program, but are you
sharing one event_base amon
Try JMeter. I believe AB has bugs.
Sent from my iPhone
On Dec 16, 2012, at 10:52 AM, Björn K. wrote:
> Hello,
>
> I'm trying to write a simple https server which utilizes multiple cpu cores.
> I call evthread_use_pthreads() and create several pthreads. My
> acceptcb and the thread worker fun
21 matches
Mail list logo
