C 自由开关阻塞

C 自由开关阻塞,c,linux,multithreading,freeswitch,C,Linux,Multithreading,Freeswitch,FreeSwitch软件在几天~3-5天内运行良好,然后新的来电请求被接受,因为FreeSwitch被阻止!!正在进行的呼叫将继续其会话,他们的呼叫似乎未生效,但新呼叫不被接受。我得到了FreeSwitch快照并在GDB中进行了分析 我有601个therads&大多数都在等待 Thread 0x7f16bc55f700 (LWP 28544) pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/p

FreeSwitch软件在几天~3-5天内运行良好,然后新的来电请求被接受,因为FreeSwitch被阻止!!正在进行的呼叫将继续其会话,他们的呼叫似乎未生效,但新呼叫不被接受。我得到了FreeSwitch快照并在GDB中进行了分析

我有601个therads&大多数都在等待

Thread 0x7f16bc55f700 (LWP 28544) pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
当我在gdb中应用线程apply all bt时,我看到大多数线程都试图将事件推送到队列开关中

Thread 600 (Thread 0x7f16bc55f700 (LWP 28544)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f180cf9b87d in apr_thread_cond_wait (cond=<optimized out>, mutex=<optimized out>) at locks/unix/thread_cond.c:68
#2  0x00007f180cf92dd0 in apr_queue_push (queue=queue@entry=0x7f180db157a8, data=data@entry=0x7f16d3d5ec20) at misc/apr_queue.c:166
#3  0x00007f180cc958fb in switch_queue_push (queue=0x7f180db157a8, data=data@entry=0x7f16d3d5ec20) at src/switch_apr.c:1134
#4  0x00007f180cd17850 in switch_event_queue_dispatch_event (eventp=0x7f16bc55ec48) at src/switch_event.c:384
#5  switch_event_fire_detailed (file=file@entry=0x7f180cfb07ea "src/switch_channel.c", func=func@entry=0x7f180cfb2ba0 <__func__.18348> "switch_channel_perform_set_running_state", line=line@entry=2260, event=event@entry=0x7f16bc55ec48, user_data=user_data@entry=0x0) at src/switch_event.c:1986
#6  0x00007f180cc9f118 in switch_channel_perform_set_running_state (channel=0x7f17e3e7de00, state=CS_NEW, file=0x7f180cfbc590 "src/switch_core_state_machine.c", func=<optimized out>, line=543) at src/switch_channel.c:2260
#7  0x00007f180ccc87d0 in switch_core_session_run (session=0x7f17e3e7fd28) at src/switch_core_state_machine.c:543
#8  0x00007f180ccc36de in switch_core_session_thread (thread=<optimized out>, obj=0x7f17e3e7fd28) at src/switch_core_session.c:1629
#9  0x00007f180ccbf47d in switch_core_session_thread_pool_worker (thread=0x7f17e3e9abb0, obj=0x80) at src/switch_core_session.c:1692
#10 0x00007f180cfa1910 in dummy_worker (opaque=0x7f17e3e9abb0) at threadproc/unix/thread.c:151
#11 0x00007f180c1e0064 in start_thread (arg=0x7f16bc55f700) at pthread_create.c:309
#12 0x00007f180b8b862d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
我为什么要这样? 如果您有任何想法、建议和窍门,我们将不胜感激。
关于,

我已经深入研究并找到了我的解决方案

为了解决这个问题,您应该了解Freeswitch的事件处理程序机制。由于有许多生产者线程生成事件并将其放入该队列,因此该机制中只存在一个消费者线程。消费者线程是已知的事件处理程序,它将事件传递给所有侦听器,例如侦听适当事件的模块

这些侦听器中的一个或多个可能会通过阻塞此使用者线程而阻塞,事件队列可能会变满。当事件队列已满时,您的feeswitch将被阻止

解决这些问题有三种解决方案:

1:在默认配置中,事件处理程序机制使用事件队列。但是,您可以使用线程解决方案来进行更改 事件在post_load_switch.conf文件中使用dispatch=false值

2:增加用户线程数,因为对于重载freeswitch服务器,单个用户线程不是好的解决方案 您可以在post_load_switch.conf文件中使用initial event threads=X来执行此操作,其中X表示初始线程数


3:在您的模块中,您也可以使用事件处理程序机制。当您从Freeswitch的核心获取事件时,创建一个新线程并将其分配到新创建的线程中,以避免等待Freeswitch的消费者线程

请出示相关代码。另见。