谁熟悉libevent库呀,我卡在evbuffer_get_length里啦

jd808

1. 读aa===1147  //这个下面就是evbuffer_get_length(m_ReadBuf);这个,有libevent提供,读取缓存长度.卡在这个函数了
   
2. close event. fd:1147, Bev:0x96bb10, conn:0x96d910 ==140737354020672
   
3. ============准备关闭句柄==============1===fd:1147

复制代码

这里有个奇怪的地方是,读线程在准备读取长度的时候卡主了(libevent里应该有吧锁),但这个时候主线程抛出了这个fd断开了,就调用关闭程序取关闭fd和缓存.由于读线程加了conn->UserCMDLock锁(保证每个句柄只能一个线程在读),为了保证在读取过程中,不关闭FD,我就在关闭函数里又加了conn->UserCMDLock锁,结果就卡主了.(关闭函数只会在主线程调用,不会和读线程冲突,这里卡主主要是读线程被卡在了evbuffer_get_length处,导致读线程不能释放锁.),请问这种情况是BUG?还是我用的不对啊.

我的结构是,主线程初始化libevent和fd接入,以及读取消息通知,工作线程通过主线程的管道,接收fd通知,在通过fd取读取消息(读取过程由libevent提供的缓存自动完成,我只读取缓存里面的消息)

ilex

gdb的bt信息是啥样子的？

jd808

ilex 发表于 2015-01-08 22:51
gdb的bt信息是啥样子的？

gdb的bt消息不准确,因为这个卡主后,线程管道那边立即就卡主了,没法往里写数据(测试的时候数据发送非常快),所以gdb的bt消息通常都是提示管道被卡主,实际是libevent被卡主了

ilex

但这个时候主线程抛出了这个fd断开了

——是怎么发现fd断开了？主动关闭还是libevent告诉你的？

jd808

ilex 发表于 2015-01-12 11:28
但这个时候主线程抛出了这个fd断开了

——是怎么发现fd断开了？主动关闭还是libevent告诉你的？

libevent告诉我的.

ilex

看起来是两把锁，两个线程互相在等对方的锁。
evbuffer_get_length(const struct evbuffer *buffer)
{
        size_t result;

        EVBUFFER_LOCK(buffer);

        result = (buffer->total_len);

        EVBUFFER_UNLOCK(buffer);

        return result;
}
这个函数在等evbuffer的锁，
还有一个锁就是你自己定义的。

jd808

ilex 发表于 2015-01-13 09:02
看起来是两把锁，两个线程互相在等对方的锁。
evbuffer_get_length(const struct evbuffer *buffer)
{

我对另外一个线程的发送代码做啦调整,以前是遍历句柄链表发送消息出去(每个都发),并且忘记加锁了,现在加了个锁,好像没这个问题了,感觉好奇怪,即使句柄被关闭或者删除,也不能出现这个长度不能读取吧.无法理解.