On 04/02/11 01:34, Adriano dos Santos Fernandes wrote: > On 01-04-2011 07:14, Alex Peshkoff wrote: >> On 03/31/11 19:13, Adriano dos Santos Fernandes wrote: >>> On 31-03-2011 07:49, Alex Peshkoff wrote: >>> >>>>> 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 >>>> >>> This is against of what you already said, and in fact destroys the >>> concept of recounting. >>> >>> If I call attachment->allocateStatement, this statement is owned by me >>> now, even if I don't call addRef on it. >>> >> Sorry. Certainly you are right - looks like I was tired in the evening >> and therefore said such foolish thing. >> > Now look at this. This, while a not very good practice, is something > very used and is how our ISC API work. > > User detachs an attachment and there is no memory leak from > transactions, blobs, statements, etc.
Not for transactions - one can't detach with active transactions. > And who generally closes all handles? Most probably languages with RAII > support, especially C++. > > But wait, to make RAII work in C++ with our API we don't need > refcounters. You're refcounters are to support another bad practice: use > after freed. Please call it 'help avoid segfault in case of races'. > So while them "fix" a very-bad practice, it makes a not so bad to leak > memory. > I.e. we must choose from 2 bad choices - one may cause memory leaks, other - random segfaults. (Why random: I agree that normally one should not use an object after detach/commit. But unfortunately races exist, and in that case an object, detached in thread A, can be used in thread B.) I prefer to avoid segfaults in case of races. They are very hard to reproduce (for example, buggy code in solaris lock manager existed for a very long time, as long as that code was not tried on linux threads, where it caused segfault due to races). Memory leaks are typically easy reproduced, and there are a lot of tools to deal with memory leaks. One who cares about this can always check for them. On contrary, I do not know a way to avoid races without reference counters built into interfaces except hard locking user code. > One cannot use free then use a pointer. One cannot delete then use a > pointer. This is bad practice. > Certainly bad practice, but once more - just to help in case of races. > On the other hand, people are used to quit an application and see no > memory leaks. They destroy a pool to not delete individual objects. And > so on. > > I think you must really think, your fix to a bad practice is done a > damage to normal usage. > A few lines before you've said yourself that not closing handles is 'a not very good practice'. >> Getting serious - certainly, an object can't be used after it's freed. >> The question is what we call 'freed'. >> In old API freed meant detach/commit was done, but even after it (if >> noone allocates about 2**32 handles) correct diagnostics about that >> usage was provided. >> >> That said - certainly people can't use object after it was >> detached/dropped/etc. But they have reasons to get correct diagnostics >> instead segfault in such a case. As we have agreed, sometimes it's very >> hard to guarantee that an attachment is alive even in the next line >> after attach was called. And what - segfault? >> > I will again must say to take another look at the problem. > > OS kernels has handles or numeric file descriptors. When user mode calls > the kernel, kernel verifies it's valid. So as our handles. Kernel validates everything, including pointers. Some libraries also validate pointers, passed to them, but this is not related to our problem. > But if a OS library returns a pointer, there is no protection to wrong > usage on them. Reference counters were designed to protect pointers, returned by some library. > User must use memory correct, or must use a language with > they don't need to deal with it directly. So as our objects must be. First of all our objects must be oriented to support that languages. And presence of reference counters is the best way to do it. I do not agree when you use as a top priority old languages. I know that they must be _minimally_ supported. But we must have new API oriented on a fresher tools, like C++/Delphi with RAII support. And help people, developing components for tools like .Net implement what they need as easy as possible. For both of this aims reference counters are useful. ------------------------------------------------------------------------------ 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
