On 03/30/11 18:44, Adriano dos Santos Fernandes wrote: > On 30-03-2011 07:23, Alex Peshkoff wrote: >> On 03/29/11 18:58, Adriano dos Santos Fernandes wrote: >>> On 29-03-2011 10:45, Alex Peshkoff wrote: >>>> We have too many problems in single thread. I try to divide it to >>>> smaller parts. >>>> The first one - here we at least all seem to talk about same thing:-) - >>>> is to use reference counters or not. >>>> >>>> On 03/28/11 22:45, Adriano dos Santos Fernandes wrote: >>>>> User should *not* request a detachment and then request actions on the >>>>> objects. This *is* user application problem, no mater it being single or >>>>> multi thread. >>>> In that case our new API is regression compared with old ISC API with >>>> handles. Pre FB3 an attempt to request actions on the objects after >>>> detachment cause correct reply from client library - invalid handle. >>>> Without reference count support we will get segfault in FB3. I treat >>>> this as serious regression. >>>> >>> You're trying to make two different worlds to look similar. >>> >>> Take another look at it. >>> >>> Thread 1 detachs and makes it handle invalid. >>> >>> Thread 2 allocs 0xFFFFFFFF handles. >>> >>> Thread 3 is scheduled to run and use the old invalid, but now valid handle. >>> >>> Very pessimistic and "impossible" to happen, but shows that application >>> doing this with handles are still incorrect. >> As you understand yourself, this is not realistic example. >> Cases when thread 3 is trying to work with old invalid handle and gets >> appropriate error message is reality. >>> You also didn't replied yet to me what will happen when you detach a >>> parent without free children: leaks or will regret your refcounters? >> Sorry, may be I've missed that question. >> The answer is simple - objects will exist until refcounters > 0, but >> will be marked in a way, making them return 'object is invalid' error >> for any request. >> > And not everyone is using C++ and RAII. This will create a lot of leaks.
You've forgotten that such people are not forced to use addRef/release at all. > People would like to detach a parent and not care about statements > created but unfreed for this attachment. > If they do not call addRef for statements, they will be destroyed when attachment goes away > And for who is using C++ and RAII, they don't need addRef/release in our > objects to use that. Absolutely wrong. > Well, if you want to say that someone is correct just because chose the > COM way, then we would need to say we're incorrect because we don't use > queryInterface... In many aspects use of queryInterface might be ideal. Two main reasons why we can't use it: - it will cause additional delays in time-critical places like fetching next record, - it will pollute each place in the code where we work with plugins. On the other hand I see no problems with adding that method to our interfaces, specially if it's needed to make Delphi people life easier. It does not conflict with our versioning support. ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
