#32 Std DLL, consequtive destroy & create session prob fix, etc
This package includes number of patches based on ver 2.0.1 .
For easy reference and diff comparisons the original and new code is here:
http://www.bttarge.com/downloads/postbox/iaxclient-2.0.1.new-orig.rar
Note that line breaks are fixed as CRLF on both.
1. On windows platforms, builds a DLL just like Windows APIs, i.e., no name mangling and stdcall calling convention :
To see the relevant modifications search for "IAXC_CALL".
Note that listVidCapDevices() is an exception at the time. It is not listed in the DEF file anyway.
2. "new\iaxclient\contrib\win\iaxclient_dll.def" file updated for version 2.0.1.
3. On windows platforms, using VS2005, builds a DLL that does NOT depend on msvrt80.dll.
For libiaxclient DEBUG_DLL and RELEASE_DLL configurations,
- module definition file set to "..\iaxclient_dll.def"
- run-time library changed to "Multithread" from "Multhreaded DLL" to prevent MSVCRT80.dll dependency.
To see the relevant mofications (including the above case-1) see "new\iaxclient\contrib\win\vs2005" directory.
4. (COMPATIBILITY BREAKING !) Suggestion : iaxc_event_callback_t param as pointer instead of whole struct, i.e.,
typedef int (IAXC_CALL *iaxc_event_callback_t)(iaxc_event *e);
instead of
typedef int (IAXC_CALL *iaxc_event_callback_t)(iaxc_event e);
The reasoning :
May be iaxc_event was small before and it was preferred to pass it by-value.
But it is quite large right now and cause "considerable" stack operations.
Besides, in the future, it may grow more.
Another point of by-value passing could be data protection (from external writes).
But this a moot point and I belive API consumers (who are developers themself) should be smart enough to use them.
5. iax.c fix at iax_get_event() { .. if (frame->final) destroy_session(frame->session); .. } :
Quick deallocation and allocation of sessions may result in the same-memory-address use !
Therefore we cannot trust remote-sent address only.
Best bet is checking by somewhat unique properties to decide if we really intend to destroy this session.
Example Case:
- Have a call
- Dump that call and immediately request a new call (or have a incoming call request by a lesser chance)
- By considerable probability, you might get the previous memory address for the new session.
- When execution hits to this point as a result of previous call ending
(as client informs server about dumping and frees the previous session,
server proccess call-dumping and eventually this point reached)
frame->session param to the destroy_session() belongs to the new & valid session !
- as a consequence many independent execution paths got broken (AV errors and such)
The fix is ( bytheway, have anyone know more reliable check value? )
if (frame->final)
if (frame->session && (frame->callno == frame->session->callno))
destroy_session(frame->session);
6. portaudio (external lib) fix :
Pa_Terminate decrements initializationCount_ before calling CloseOpenStreams() and that results in left-open streams.
This is especially problem when the top level application is shutting down:
when pa_win_wmme::ProcessingThreadProc() is running but many objects (events, callbacks, etc.) are destroyed.
The fix is
if( initializationCount_ == 1 )
CloseOpenStreams();
before
if( --initializationCount_ == 0 )
See "new\pa_front.c"
7. Delphi (7) files "new\iaxclient\contrib\win\d7\"
- "libIAXClient.pas" : the API
- "libIAXClientGateWay.pas" : a sample "thread-safe" gateway
