Hi,
o Jeremy A [08/28/09 10:17]:
Hi,
I have discovered a type of race condition in SEMS startup ( rev 1.1.1 )
. My sems.conf contains
load_plugins=wav;unixsockctrl;multicall (multicall is my application)
Despite unixsockctrl being listed before multicall, multicall is
initialized first, then unissockctrl. This is only a problem if the
first thing I do in multicall factory is make some outgoing calls - at
which point sems core dumps. (It also fails when multicall is listed
before unixsockctrl)
first the plugins are loaded, then initialized, and then several threads
are started (session container, media processor, rtp receiver, SIP
server thread).
In your multicall app, you can start another thread in the onLoad
function, and in that thread wait a little while until everything is
initialized.
Something like
class MCallThread : public AmThread {
public:
void run() {
sleep(5);
...start the calls...
}
void on_stop();
};
MCallFactory::onLoad() {
MCallThread* thr = new MCallThread();
thr->start();
AmThreadWatcher::instance()->add(thr); // no mem leak
}
hth
Stefan
If I remove the first set of calls in my app then all is O.K.
unixsockctrl starts up and subsequent calls work.
Alternatively. If I put a long delay in my app startup, then the system
simply stops and unixsockctrl does not start. At the end of timeout I
get the coredump.
I guess this is a request for some sort of priority in plugin startup.
Or some alternate way to get my calls going out only when the interfaces
are fully constructed.
Any help appreciated.
Jeremy
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
--
Stefan Sayer
VoIP Services
[email protected]
www.iptego.com
IPTEGO GmbH
Wittenbergplatz 1
10789 Berlin
Germany
Amtsgericht Charlottenburg, HRB 101010
Geschaeftsfuehrer: Alexander Hoffmann
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
