SipXtapi Meeting Log - Singleton Initialization - 20070511
From SIPfoundry sipx, The Open Source SIP PBX for Linux - Calivia
Conversation with sipxtapi@conference.jabber.ru on 5/11/2007 10:09:07 AM:
(10:09:08 AM) yarol1 entered the room.
(10:09:08 AM) sergforce entered the room.
(10:09:08 AM) Alexander.Chemeris entered the room.
(10:09:08 AM) daniel.g.petrie entered the room.
(10:09:08 AM) kamaji entered the room.
(10:03:30 AM) yarol1: hi
(10:03:46 AM) kamaji: Hello
(10:03:55 AM) daniel.g.petrie: Hello
(10:09:11 AM) sergforce: hello
(10:09:24 AM) Alexander.Chemeris: hello all
(10:09:29 AM) Alexander.Chemeris: Seems we're ready?
(10:10:11 AM) sipxtapi@conference.jabber.ru: Alexander.Chemeris has set the topic to: Singletons initialization
(10:10:12 AM) yarol1: yes
(10:12:12 AM) daniel.g.petrie: The goal is to make static initialization more predictable or better behaved. However a very import requirement or constraint is that we do not increase the dependencies
(10:13:38 AM) daniel.g.petrie: we cannot make changes that cause every class with a static to get linked into every executable. This creates a big problem for embedded devices and library modularity
(10:14:31 AM) yarol1: the approach described by Steven Steel does increase dependencies, but is the only compiler independent way to get rid of leaks
(10:15:06 AM) yarol1: the 2nd approach by using static member inside function works only if no other constructor or destructor requires this member
(10:15:19 AM) yarol1: otherwise destructor ordering might be wrong
(10:16:01 AM) yarol1: we would only have to use the 1st approach in sipxportlib, not in other libraries
(10:16:23 AM) kamaji: Is there a way to combine Approach #2 with approach #1?
(10:16:34 AM) yarol1: as long as in other libraries, there are no dependencies between static variables
(10:17:48 AM) yarol1: it depends on the library
(10:18:40 AM) yarol1: in portlib, there are many static objects that need to be initialized in the right order
(10:20:01 AM) yarol1: we dont need to be scared of it in portlib, as its basically OsTime::OS_INFINITY, OsTime::NO_WAIT, OsTime::NO_WAIT_TIME, UtlContainer::spIteratorConnectionLock, UtlLink::spLinkPool, UtlPair::spPairPool, OsNameDb::spInstance, OsProtectEventMgr::spInstance
(10:20:40 AM) yarol1: I think most of your programs would use these in a way anyway, except maybe OsNameDb
(10:20:45 AM) kamaji: Perhaps we have a cascaded .h file -- portlib.h includes a number of includes each with a reduced set of statics
(10:20:55 AM) yarol1: .
(10:21:24 AM) kamaji: hrm
(10:21:44 AM) kamaji: no, I dont think that would work, as the order needs to be held *within* portlib
(10:21:52 AM) yarol1: UtlLink and UtlContainer, OsTimer are always linked I would say
(10:21:57 AM) kamaji: (replying to myself)
(10:22:29 AM) Alexander.Chemeris: 2kamaji: what is the problem with cascading?
(10:22:39 AM) yarol1: I created an issue for this > http://track.sipfoundry.org/browse/XPL-204
(10:23:07 AM) yarol1: the PortLib.cpp doesn't have to contain the static initialization except the stuff in PortLib::PortLib(void)
(10:23:28 AM) yarol1: stuff like const long OsTime::MSECS_PER_SEC = 1000; is guaranteed to be initialized first
(10:23:39 AM) yarol1: because it doesn't depend on anything
(10:24:01 AM) yarol1: if it was const long OsTime::MSECS_PER_SEC = x + y + 1; then it would be different
(10:25:32 AM) yarol1: I propose using the 1st approach in portlib only, once that is done, its safe to use static singletons in tacklib and elsewhere, provided we check constructors & destructors of the singleton itself and of other static singletons
(10:26:05 AM) Alexander.Chemeris: What do you mean by "check"?
(10:26:14 AM) yarol1: this will mean all singletons in portlib will be automatically linked, but not the stuff from tacklib, if you don't use it
(10:26:47 AM) yarol1: we would have to proofread all static constructors and destructors alexander
(10:27:11 AM) yarol1: you can't use other static singletons in constructor or destructor
(10:27:36 AM) yarol1: except the ones from portlib if this approach is used
(10:28:06 AM) yarol1: also other static singletons cant use your singleton in constructor or destructor
(10:28:29 AM) yarol1: if we keep this in mind, we can use safe static singletons
(10:29:48 AM) Alexander.Chemeris: Ok, this sounds fine for me with one addition - we might want to split portLib initialization to several "sublibs".
(10:31:18 AM) Alexander.Chemeris: I believe we have "time" part, "UTL" part, "OsNameDb" and "
OsProtectEventMgr"
(10:31:39 AM) kamaji: but some of them depend on each other..
(10:31:42 AM) kamaji: time and utl
(10:31:46 AM) kamaji: I believe
(10:31:54 AM) yarol1: the locks depend on OsTime too
(10:32:16 AM) yarol1: and basically everything depends on UtlPair and UtlLink
(10:32:29 AM) daniel.g.petrie: I think the thing to do is define a clear order of dependency between this parts
(10:32:49 AM) yarol1: you can have a look at my PortLib.cpp
(10:33:10 AM) daniel.g.petrie: make a clear heirarchy and then force the highest to initialize the lower part first
(10:33:51 AM) yarol1: the problem is, the top part doesn't know whether you really need for example OsProectEventMgr
(10:34:04 AM) daniel.g.petrie: so Locks part forces OsTime part to initialize prior to Locks
(10:34:20 AM) daniel.g.petrie: and OsTime part forces Utl part to initialize before OsTime
(10:34:43 AM) daniel.g.petrie: then we have three parts still and only downward dependency
(10:35:47 AM) Alexander.Chemeris: 2yarol: do you mean OsTime::MSECS_PER_SEC and friends?
(10:36:16 AM) yarol1: MSECS_PER_SEC is fine, its initialized before any static constructors are executed
(10:36:28 AM) yarol1: because it is initialized with a constant
(10:36:34 AM) daniel.g.petrie: why isn't OsProtectedEventMgr the top most dependent part of portLib?
(10:37:29 AM) Alexander.Chemeris: 2yarol: What is the problem then?
(10:37:48 AM) yarol1: the problem is when you have UtlChainPool UtlLink::spLinkPool;
(10:38:11 AM) yarol1: and somebody else tries to use spLinkPool before its construted
(10:38:43 AM) yarol1: OsProtectEventMgr should probably be just after OsTime I think
(10:38:55 AM) Alexander.Chemeris: 2Dan: What is OsProtectedEvent? When it is used?
(10:39:38 AM) daniel.g.petrie: It is used to pool OsEvents. It is used in the sipStack and mediaLibs
(10:39:39 AM) yarol1: the order in PortLib.cpp should be correct except for OsProtectEventMgr
(10:39:47 AM) daniel.g.petrie: Not sure where else
(10:39:58 AM) kamaji: It is used at least in MprFromFile.playBuffer to send status events back up to the flowgraph/application.
(10:40:16 AM) kamaji: but it seems there's no need for OsProtectedEvent in that case.
(10:40:40 AM) kamaji: and it's pretty useless down in playBuffer too.
(10:41:53 AM) daniel.g.petrie: frankly I am not sure OsProtectedEvent is useful at all. It was created with a lack of understanding of how to safely use an OsEvent between two parties.
(10:42:33 AM) Alexander.Chemeris: 2Dan: It's different discussion :)
(10:42:56 AM) daniel.g.petrie: The idea being that both sides call release. It is not necessary if you look to see if the OsEvent has been signalled or not
(10:43:16 AM) daniel.g.petrie: yes, but it it is a problem. Lets get rid of it
(10:43:41 AM) Alexander.Chemeris: 2dan: set time for next coneference?
(10:44:21 AM) daniel.g.petrie: do we have a topic or shall we plan on having these once a week and find a topic?
(10:44:59 AM) yarol1: I think its not a problem to find a topic for every week :)
(10:45:00 AM) Alexander.Chemeris: I vote for on demand conferences
(10:45:38 AM) Alexander.Chemeris: 2yarol: I'm still not sure I understand what is the problem with cascaded initialization. What's wrong if in UtlInitilizer.h we'll include 'static OsTimeInitializer timInit;'?
(10:46:12 AM) kamaji: on-demand conferences, with a predefined time once a week (say, this time, since we've been doing it).. so if there happens to be a week that we don't have anything useful to talk about - no need for meeting.
(10:46:18 AM) yarol1: that would work too alexander, but we would have more instances of these init clases
(10:46:21 AM) Alexander.Chemeris: Sure, but we should solve problems one after other - we have to start next topic once previous would be solved
(10:46:49 AM) Alexander.Chemeris: I do not think it's a problem - init classes do not consume memory
(10:46:59 AM) yarol1: they do alexander
(10:47:14 AM) yarol1: you have 1 instance for each cpp file where you include the h file
(10:47:34 AM) kamaji: small amount of memory, but it exists.
(10:47:37 AM) daniel.g.petrie: Alex: Isn;t it the other way around. In OsTime intialize we force intiailization of Utl?
(10:47:51 AM) yarol1: 1 instance shouldnt take much memory though, as it has only 1 member and no virtual methods
(10:48:13 AM) Alexander.Chemeris: yep, you're right
(10:49:27 AM) Alexander.Chemeris: Next thought - we may include 'static PortLiInit portLibInit' just to UtlInit.cpp
(10:49:47 AM) yarol1: no alex, it wouldnt work
(10:50:06 AM) Alexander.Chemeris: ah, sure, my bad
(10:50:06 AM) yarol1: thats the solution for constructor/destructor ordering problem, to declare it in h file
(10:51:03 AM) yarol1: you could split the init to several classes in case you just need part of portlib
(10:51:25 AM) yarol1: but how often does that happen?
(10:51:36 AM) yarol1: is portlib used anywhere else?
(10:52:00 AM) kamaji: i.e. in other non-sipX projects?
(10:52:03 AM) yarol1: yes
(10:52:15 AM) kamaji: not sure..
(10:52:18 AM) daniel.g.petrie: I had a client just a few months ago that wanted to use part of portlib without dragging the whole thing in
(10:54:18 AM) daniel.g.petrie: they wanted to use OsConfigDb on and embedded device so that it could be compatible with a server product that was using sipXtapi.
(10:54:23 AM) Alexander.Chemeris: re: many instances of initializers: As I understand you propose to include your PortLib class static variable only to cpp files where other stataic variables are initialized, right?
(10:54:35 AM) yarol1: yes alex
(10:54:59 AM) daniel.g.petrie: OsConfigDb dragged in a huge amount of code. It is just a hash table and a simple parser
(10:55:20 AM) Alexander.Chemeris: ok, then if we include 3 such initializer instead of 1 it wouldn't be much worse.
(10:55:56 AM) Alexander.Chemeris: It will be worse if it would be included in huunderds cpps
(10:56:03 AM) yarol1: daniel, they could always comment out a few lines in PortLib.cpp
(10:56:06 AM) daniel.g.petrie: the three would give us much better granularity though
(10:56:16 AM) yarol1: and use just part of it
(10:56:38 AM) daniel.g.petrie: making changes like that is awkward with LGPL
(10:57:02 AM) Alexander.Chemeris: I'm thinking about configure switch to exclude some parts of portLib also..
(10:57:24 AM) Alexander.Chemeris: But I believe granular initializers would be much better
(10:57:27 AM) yarol1: its common daniel to compile libraries without some functionality
(10:58:01 AM) yarol1: so special #defines could be used to enable or disable parts of portlib
(10:59:03 AM) daniel.g.petrie: there will never be the optimum set of configure switches for any particular user. It will either evolve into a mess or people will not use it
(10:59:39 AM) daniel.g.petrie: that is the whole point of having separate class files and a library
(11:00:27 AM) daniel.g.petrie: otherwise we might as well just product one big .o file
(11:03:21 AM) yarol1: so do you want to split it into 4 parts then? OsTime, Utl*, OsNameDb and OsProtectEventMgr ?
(11:04:08 AM) yarol1: there are also some other singletons I haven't touched, like OsTimerTask
(11:04:17 AM) kamaji: We're now talking about producing 1 static initializer header or 3 hierarchical static initializer headers vs a configure-based approach to add/remove portions of PortLib?
(11:04:33 AM) yarol1: yes
(11:04:40 AM) kamaji: ok
(11:06:06 AM) yarol1: in case of configure-based approach the ifdefs could be just in PortLib.cpp, to avoid mess
(11:10:43 AM) Alexander.Chemeris: I still vote for granular initializers, as it's more automatic way. I do not like to put to much on user
(11:11:01 AM) Alexander.Chemeris: Dan, your word?
(11:11:02 AM) daniel.g.petrie: I agree with more granular
(11:11:12 AM) kamaji: I agree as well.
(11:11:45 AM) Alexander.Chemeris: Jaroslav, what is your obections to it?
(11:12:27 AM) yarol1: I think it's not needed but if you want it I'm fine with it
(11:12:50 AM) Alexander.Chemeris: ok. So, we're agreed on this
(11:13:07 AM) Alexander.Chemeris: Next qestion - about naming
(11:14:07 AM) Alexander.Chemeris: I think about *Init class names, e.g. SipxPortLibInit, UtlInit and so on
(11:14:20 AM) Alexander.Chemeris: Any better ideas/objections?
(11:15:44 AM) yarol1: I agree, the question is only how many of these Init classes you want
(11:17:20 AM) kamaji: well, from before, here's what we have to initialize, at least in part:
(10:20:01 AM) yarol1: we dont need to be scared of it in portlib, as its basically OsTime::OS_INFINITY, OsTime::NO_WAIT, OsTime::NO_WAIT_TIME, UtlContainer::spIteratorConnectionLock, UtlLink::spLinkPool, UtlPair::spPairPool, OsNameDb::spInstance, OsProtectEventMgr::spInstance
(11:18:19 AM) yarol1: OsTime is needed by the locks, locks are needed by Utl stuff
(11:18:33 AM) yarol1: OsNameDb needs Utl stuff
(11:18:40 AM) Alexander.Chemeris: I think we'd agreed with 4 initializers
(11:19:04 AM) yarol1: alexander there is also OsTimerTask and other singletons
(11:19:38 AM) yarol1: I didn't put OsTimerTask there, because it gets special treatment in sipxtapi, it is destroyed during shutdown
(11:20:00 AM) yarol1: but maybe it would be best if it was destroyed automatically too
(11:20:15 AM) Alexander.Chemeris: I believe it's destroyed there only because it isn't destroyed in portLib
(11:20:46 AM) yarol1: its destroyed there to kill all timers
(11:21:04 AM) Alexander.Chemeris: If we will destroy it safely in out initializers, then we could remove its destruction from sipXtapi
(11:21:25 AM) Alexander.Chemeris: To kill all timers? It's a hack then.
(11:21:38 AM) Alexander.Chemeris: I believe timers should be stopped gracefully
(11:22:16 AM) Alexander.Chemeris: And destroying it in sipXtapi ia bad idea anyway, because application may want use timers after sipXtapiUninitialize
(11:22:17 AM) yarol1: there are many hacks in sipxtapi :)
(11:22:32 AM) Alexander.Chemeris: Our goal is to remove them
(11:22:35 AM) yarol1: there was also garbage collector to delete semaphore in call safely :)
(11:22:46 AM) Alexander.Chemeris: I believe it's a good time to get rid of this one
(11:24:45 AM) yarol1: then there is also this UtlListIterator::NOWHERE thing
(11:25:27 AM) yarol1: and maybe 2 more static members like this, I don't know exactly I would have to run wxCommunicator with visual leak detector
(11:25:40 AM) daniel.g.petrie: Sorry this is a bit of a tangent, but there are statics that do not need to be static. THe OsTime statics could easily be # defines or something
(11:26:04 AM) yarol1: sure
(11:26:15 AM) yarol1: I dont know why they were made static and not numbers
(11:26:31 AM) Alexander.Chemeris: Sure, I believe OsTime ones should be primitive types, e.g. int or so
(11:26:45 AM) yarol1: the problem is, OS_INFINITY, NO_WAIT and NO_WAIT_TIME are used on lots of places
(11:26:47 AM) daniel.g.petrie: If we can clean up a few of these things to make this simpler, I think it is worth it
(11:27:46 AM) daniel.g.petrie: can't they just be made enums? with appropriate values?
(11:28:08 AM) yarol1: no they are default parameter to some methods requiring OsTime&
(11:28:31 AM) daniel.g.petrie: such that the constructor for Osime will use to
(11:28:46 AM) daniel.g.petrie: construct an implicit OsTime
(11:28:52 AM) yarol1: those methods would have to be duplicated to accept numbers as well
(11:29:16 AM) Alexander.Chemeris: if they are 'const OsTime &' then it's not a problem
(11:29:27 AM) daniel.g.petrie: right
(11:29:38 AM) yarol1: for example OsUtilWnt::synchObjAcquire
(11:29:40 AM) daniel.g.petrie: they should be const anyway
(11:29:58 AM) yarol1: static OsStatus synchObjAcquire(const HANDLE synchObj, const OsTime& rTimeout = OsTime::OS_INFINITY);
(11:30:08 AM) daniel.g.petrie: if they are not we will get a compliation error and we will know where to change it to const
(11:30:36 AM) Alexander.Chemeris: as long as it's const compiler will create temporary variable
(11:31:11 AM) daniel.g.petrie: I do not think it will do that for arguement defualts like in Jaroslav's example
(11:31:54 AM) yarol1: yes because there is no = operator in OsTime that accepts a number
(11:32:20 AM) kamaji: well then..
(11:32:25 AM) kamaji: perhaps one needs to be created.
(11:32:35 AM) yarol1: but OsTime has long mSeconds;
long mUsecs;
(11:33:02 AM) daniel.g.petrie: oh, yeah, that is not a big deal to do
(11:33:27 AM) Alexander.Chemeris: we have constructor that accept msecs as only parameter
(11:33:32 AM) daniel.g.petrie: we already have a constructor that takes one argument. I think it assumes it is seconds
(11:33:40 AM) daniel.g.petrie: oh
(11:34:41 AM) Alexander.Chemeris: so we may create operator= that accept msecs too
(11:34:44 AM) Alexander.Chemeris: right?
(11:35:18 AM) daniel.g.petrie: yeah. It would have to recognize the biggest long or int as meaning infinite
(11:35:41 AM) yarol1: then OS_INFINITY could be -1 or something, NO_WAIT = 0
(11:35:54 AM) yarol1: NO_WAIT_TIME = 0 too
(11:36:04 AM) kamaji: I could swear that there already was a constructor with just long msecs
(11:36:15 AM) yarol1: or OS_INFINITY would be 0x7FFFFFFF
(11:36:30 AM) yarol1: like in OsTime::OS_INFINITY = new OsTime(0x7FFFFFFF,0x7FFFFFFF);, but it would be shorter infinity :)
(11:36:34 AM) daniel.g.petrie: we need to remove NO_WAIT only NO_WAIT_TIME should be used
(11:36:46 AM) daniel.g.petrie: that is a reminant of the merge from main
(11:36:56 AM) Alexander.Chemeris: I think OS_INFINITY should be -1
(11:37:25 AM) daniel.g.petrie: Keith: there is a constructor we need =operator
(11:37:33 AM) kamaji: ahh right
(11:37:46 AM) yarol1: alex -1 will be fine, in OsUtilWnt::synchObjAcquire we have if (rTimeout.isInfinite())
msecsTimer = INFINITE;
else anyway
(11:38:04 AM) kamaji: int64 assignment operator - msecs?
(11:38:26 AM) Alexander.Chemeris: 2Keith: What do you mean?
(11:38:33 AM) daniel.g.petrie: please minimize the use of Int64
(11:39:06 AM) daniel.g.petrie: It is not supported well on all platforms
(11:39:06 AM) kamaji: just trying to figure out a way to get the precision necessary for this assignment operator
(11:39:44 AM) kamaji: or is precision not necessary? is seconds fine?
(11:40:15 AM) yarol1: I think msecs is more useful
(11:41:17 AM) Alexander.Chemeris: I believe long with msecs would be fine
(11:42:05 AM) Alexander.Chemeris: It's usually used for rather small amounts of time, like several seconds
(11:42:43 AM) Alexander.Chemeris: If you want full precision - use full constructor with secs and usecs
(11:42:50 AM) kamaji: *nod*
(11:43:12 AM) Alexander.Chemeris: So, have we agreed on this
?
(11:43:22 AM) yarol1: I agree
(11:43:47 AM) Alexander.Chemeris: ok
(11:43:47 AM) yarol1: also get rid of NO_WAIT
(11:45:01 AM) kamaji: so to summarize timer sub-discussion
(11:45:52 AM) kamaji: Add assignment operator to OsTimer that takes long msecs
(11:47:12 AM) kamaji: make all methods that use these static OsTime objects like OS_INFINITY as const OsTime& if not alread
(11:47:43 AM) kamaji: Change all these static OsTime objects to instead be held in an enum.
(11:48:32 AM) kamaji: is that correct?
(11:48:52 AM) Alexander.Chemeris: I believe yes
(11:48:58 AM) yarol1: and fix OsUtilWnt::synchObjAcquire
(11:49:47 AM) Alexander.Chemeris: Why should we fix it?
(11:49:58 AM) yarol1: also fix OsTime::isInfinite
(11:50:01 AM) kamaji: synchObjAcquire doesn't take const OsTime& right now?
(11:50:14 AM) yarol1: you need to fix the body of the method
(11:50:58 AM) yarol1: hmm sorry, u dont have to if you make the operator = interpret -1 to be a special value
(11:51:13 AM) yarol1: and sets seconds and usecs to infinite value
(11:51:44 AM) yarol1: then you only have to fix OsTime::isInfinite which assumes OS_INFINITY if an object
(11:52:01 AM) Alexander.Chemeris: great
(11:52:02 AM) yarol1: there will be more places like that
(11:52:14 AM) kamaji: *nod*
(11:52:28 AM) kamaji: but the only high valued default should be OS_INFINITY?
(11:53:03 AM) yarol1: OS_INFINITY should be -1, operator = will interpret it as a special value and set OsTime to infinite time
(11:53:08 AM) daniel.g.petrie: Cool. Sounds like a great plan for some clean up
(11:53:39 AM) yarol1: this is needed because a long OS_INFINITY can't have the range of old OS_INFINITY
(11:53:56 AM) yarol1: old OS_INFINITY was 2x long set to max value
(11:55:12 AM) kamaji: *nod*
(11:56:06 AM) yarol1: i will recompile portlib with my patch to find out other static leaks
(11:58:29 AM) kamaji: Is there any time when OsTime can hold negative values?
(11:58:39 AM) kamaji: or shall I say, - where that is useful
(12:02:45 PM) yarol1: theoretically you could use + operator to add 2 instances of OsTime, one being negative
(12:09:01 PM) yarol1: ok other leaks are UtlListIterator::NOWHERE, OsTimerTask::sLock
(12:09:24 PM) yarol1: OsTimerTask could be made a static singleton too
(12:10:02 PM) Alexander.Chemeris: *nod*
(12:11:36 PM) Alexander.Chemeris: What is the problem with NOWHERE? Could it be put to UtlInit initializer?
(12:11:48 PM) yarol1: yes
(12:12:16 PM) Alexander.Chemeris: great.
(12:12:17 PM) yarol1: it doesnt have to be static at all though
(12:12:29 PM) Alexander.Chemeris: Looks like we've discussed all the things?
(12:13:28 PM) yarol1: I will have a look at the leaks again, I had to recompile sipxtapi
(12:14:08 PM) Alexander.Chemeris: ok
(12:14:40 PM) yarol1: OsSysLogTask could be static too
(12:15:01 PM) yarol1: OsSysLog::initialize should just set some options on it, not create it
(12:15:23 PM) yarol1: unless you want to keep it that way
(12:17:53 PM) yarol1: then we have TapiMgr::spTapiMgr in tacklib that would be made just static after these changes in portlib
(12:18:26 PM) yarol1: then you can do something with MpCodecFactory::spInstance
(12:18:43 PM) yarol1: CSourceDescription::m_spoLocalSDES
(12:18:56 PM) yarol1: CRTCManager::m_spoRTCManager
(12:19:23 PM) yarol1: NetInTask::spInstance isnt deleted either
(12:20:20 PM) yarol1: I can have a look at NAT_AGENT_EXTERNAL_CONTEXT* pContext = new NAT_AGENT_EXTERNAL_CONTEXT ; in OsNatAgentTask::addExternalBinding as it leaks too
(12:21:15 PM) kamaji: ok
(12:22:03 PM) yarol1: I can paste the log into mailinglist so that you can see it
(12:22:14 PM) sergforce left the room.
(12:22:15 PM) yarol1: the log shows the leaks after my patch
(12:23:16 PM) kamaji: ok
(12:23:34 PM) Alexander.Chemeris: Would it be useful? I think it woul dbe better to get rid of them and create new patch
(12:23:44 PM) Alexander.Chemeris: And then post it to tracker
(12:24:37 PM) yarol1: there are still 21 leaks after the patch
(12:24:54 PM) Alexander.Chemeris: In portLib or upper?
(12:24:55 PM) yarol1: too many to get rid of in 1 patch, I want them to be easily accessible for anyone
(12:24:59 PM) yarol1: in all libraries
(12:25:43 PM) yarol1: before the patch and before some of my fixes, there were like 1200 leaks :)
(12:26:19 PM) yarol1: most of the singletons though, but they hide the real leaks as they are dificult to find in the long list
(12:28:04 PM) yarol1: not all leaks are caused by the code at the bottom of the stack, some of them are caused by code in the middle
(12:35:52 PM) yarol1: it requires moderator approval :(
(12:37:35 PM) yarol1: I sent it again as tar.bz2
(12:56:46 PM) yarol1: I fixed the leak in OsNatAgentTask::addExternalBinding
(1:06:36 PM) yarol1: so who does what?
(4:00:31 PM) yarol1: .
