On Thu, Apr 29, 2010 at 5:19 AM, Sebastian Sjöberg
wrote:
> Hi,
>
> I've encountered a problem with openssl bufferevents where libevent reports
> fd:s as writeable but no action is being taken.
I think Mike Smellie finally tacked this down in his comments in bug
http://sourceforge.net/tracker/?
On May 18, 2010, at 9:33 PM, Nick Mathewson wrote:
> On Thu, Apr 29, 2010 at 2:14 PM, Sebastian Sjöberg
> wrote:
> [...]
>>> If it's the second problem, I'd start by testing whether stuff begins
>>> to work when you set the EVENT_NOEPOLL environment variable. If so,
>>> then the bug is probably
On Thu, Apr 29, 2010 at 2:14 PM, Sebastian Sjöberg
wrote:
[...]
>> If it's the second problem, I'd start by testing whether stuff begins
>> to work when you set the EVENT_NOEPOLL environment variable. If so,
>> then the bug is probably with the epoll backend -- or at least, it
>> requires the ep
On Thu, Apr 29, 2010 at 2:14 PM, Sebastian Sjöberg
wrote:
[...]
> Cheers, I haven't yet been able to reproduce it when disabling epoll.
>
> I've started to debug the evmap_io_active calls and after a while there are a
> no events being activated as you said so I guess at some point the there's a
On Apr 30, 2010, at 11:48 AM, Pavel Pisa wrote:
> Hello All,
>
Hi,
Thanks for the nice information.
[...]
>
> You can easily check, if this is cause of your troubles
> by running same code on 2.6.30+ kernel.
> If you need correct behavior even on older kernels,
> then it can be problematic.
Hello All,
it is possible, that you see same problem, which I have
observed on my ulevpoll backend for epoll syscall.
The kernel processing of wait queues does not distinguish
if the event if the event is POLLIN or POLLOUT when both
events are reported by single wait queue. The layer reporting
ev
On Apr 29, 2010, at 6:35 PM, Nick Mathewson wrote:
> On Thu, Apr 29, 2010 at 5:19 AM, Sebastian Sjöberg
> wrote:
>> Hi,
>>
>> I've encountered a problem with openssl bufferevents where libevent reports
>> fd:s as writeable but no action is being taken.
>
> [...]
>> There is no problem when I'm
On Thu, Apr 29, 2010 at 5:19 AM, Sebastian Sjöberg
wrote:
> Hi,
>
> I've encountered a problem with openssl bufferevents where libevent reports
> fd:s as writeable but no action is being taken.
[...]
> There is no problem when I'm connecting without tls so I think this is an
> issue with opens
On Thu, Apr 29, 2010 at 3:41 AM, W.C.A. Wijngaards wrote:
> (From man SSL_write):
> As at any time a re-negotiation is possible, a
> call to SSL_write() can also cause read operations!
>
> It is different from normal socket operations, so maybe an interesting fact.
I haven't looked at li
On Apr 29, 2010, at 12:59 PM, Springande Ulv wrote:
> From my experience such "while-true" loops are typically created if you
> neglect to check if the connection was closed on the client side and instead
> reinsert the connection in libevent. In this case libevent will immediately
> report tha
From my experience such "while-true" loops are typically created if you neglect
to check if the connection was closed on the client side and instead reinsert
the connection in libevent. In this case libevent will immediately report that
the connection is readable.
On 29. apr. 2010, at 12.10, S
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
(From man SSL_write):
As at any time a re-negotiation is possible, a
call to SSL_write() can also cause read operations!
It is different from normal socket operations, so maybe an interesting fact.
Best regards,
Wouter
On 04/29/20
On Apr 29, 2010, at 11:19 AM, Sebastian Sjöberg wrote:
> Hi,
Some additions and corrections. I've tested this on the latest libevent from
git.
>
> I've encountered a problem with openssl bufferevents where libevent reports
> fd:s as writeable but no action is being taken.
After adding some m
Hi,
I've encountered a problem with openssl bufferevents where libevent reports
fd:s as writeable but no action is being taken.
The program does the following:
An evconnlistener waits for connections and when an connection by a client is
made we set up an reading event. When the new connection
14 matches
Mail list logo
