Re: [Firebird-devel] Semantics of release
On 05/17/11 19:34, Adriano dos Santos Fernandes wrote:
> On 17/05/2011 04:05, Alex Peshkoff wrote:
>> In FB2.5 yValve did not need any more MT-safeness except provided by
>> atomic counters and some helper locks like hanlers' map RwLock.
>> Initially I've planned to keep same approach for FB3. But I did not
>> review latest Adriano's changes from this POV.
>>
> I already show you that 2.5 yvalve is not thread safe. Once more.
>
> How do you expect this code to work concurrently?
>
> --
> Statement statement = translate(stmt_handle);
>
> statement->checkPrepared();
> sqlda_sup::dasup_clause& clause =
> statement->das.dasup_clauses[DASUP_CLAUSE_select];
>
> if (clause.dasup_info_len && clause.dasup_info_buf)
> {
> iterative_sql_info(status,
> stmt_handle,
> sizeof(describe_select_info),
> describe_select_info,
> clause.dasup_info_len,
> clause.dasup_info_buf,
> dialect,
> sqlda);
> }
> --
>
> Accessing same memory, extending internal buffers, etc.
Good point, but I did not mean abuse of API. I only wanted to say that
under normal circumstances there are no race conditions that may cause
server to segfault/hang.
--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [pkg-firebird-general] Bug#626931: Bug#626931: Bug#626931: FTBFS on GNU/Hurd
Hi, Marius! > We need a new define for hurd Do you need help in creating prefix.hurd_i386 file? > afther we undefine LINUX that part compiles but i hit another issues > that i found it to be in haikuos too > > g++ -I../src/include/gen -I../src/include -I../src/vulcan -DNAMESPACE=Vulcan > -gg >db -p -Wall > -Wno-switch -DLINUX -pipe -MMD -fPIC -DFB_SEND_FLAGS=MSG_NOSIGNAL -D A bit strange that I once again see -DLINUX here. >DEV_BUILD > -pthread -DBOOT_BUILD -pthread -fno-rtti -c ../src/jrd/os/posix/isc_ip >c.cpp -o > ../temp/boot/jrd/isc_ipc.o > > ../src/jrd/os/posix/isc_ipc.cpp: In function 'bool isc_signal2(int, > FPTR_VOID, v >oid*, ULONG)': > > ../src/jrd/os/posix/isc_ipc.cpp:187:31: error: 'SA_SIGINFO' was not > declared in >this scope > > ../src/jrd/os/posix/isc_ipc.cpp: In function 'void > ISC_signal_cancel(int, FPTR_V >OID_PTR, > void*)': > > > http://mapopa.blogspot.com/2010/06/firebird-database-porting-progress-on.html > > ps here is one kvm-linux, qemu image that can be used Sorry, now I do not have enough free time to experiment with hurd myself. But will always be glad to help with advice. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Semantics of release
On 05/16/11 21:00, Vlad Khorsun wrote: > We can introduce some special mode to report such errors using exceptions, > or write message into log, or even provide callback for debugging purposes. > > But Adriano's question was about *semantics*. So, do you agree with me > that > explicit detach() must be called by good code and not just release() ? And > that > call of release() when refCount == 1 is a bug in caller's code ? > > Regards, > Vlad > > -- > Achieve unprecedented app performance and reliability > What every C/C++ and Fortran developer should know. > Learn how Intel has extended the reach of its next-generation tools > to help boost performance applications - inlcuding clusters. > http://p.sf.net/sfu/intel-dev2devmay > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel > > -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Semantics of release
> On 17-05-2011 19:58, Vlad Khorsun wrote: >>> PS: There is a paper >>> (http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf) from Scott >>> Meyers and Andrei Alexandrescu showing even or volatile usage in base >>> classes are wrong. Unfortunately it's down. >> >> With MSVC we are safe as we use "volatile" and compiler used read\write >> memory >> barriers (or acquire\release semantics) for access to volatile variables : >> >> http://msdn.microsoft.com/en-us/library/ms686355.aspx >> >> Can't said for other compilers (GCC at the first place). >> > Most usage of volatile to implement double-check locking pattern is in > platform neutral code, hence wrong. We can or use compiler-\arch- specific read\write barriers, or use interlocked access for InitMutex::flag and InitInstance::flag. At first look i'm not found very hot singletons at our code, so cost of full memory barriers (because of interlocked access) could be acceptable for us. Regards, Vlad -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Semantics of release
On 17-05-2011 19:58, Vlad Khorsun wrote: >> PS: There is a paper >> (http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf) from Scott >> Meyers and Andrei Alexandrescu showing even or volatile usage in base >> classes are wrong. Unfortunately it's down. > > With MSVC we are safe as we use "volatile" and compiler used read\write > memory > barriers (or acquire\release semantics) for access to volatile variables : > > http://msdn.microsoft.com/en-us/library/ms686355.aspx > > Can't said for other compilers (GCC at the first place). > Most usage of volatile to implement double-check locking pattern is in platform neutral code, hence wrong. Adriano -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Semantics of release
> PS: There is a paper > (http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf) from Scott > Meyers and Andrei Alexandrescu showing even or volatile usage in base > classes are wrong. Unfortunately it's down. With MSVC we are safe as we use "volatile" and compiler used read\write memory barriers (or acquire\release semantics) for access to volatile variables : http://msdn.microsoft.com/en-us/library/ms686355.aspx Can't said for other compilers (GCC at the first place). Regards, Vlad -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [pkg-firebird-general] Bug#626931: Bug#626931: Bug#626931: FTBFS on GNU/Hurd
On Tue, May 17, 2011 at 7:11 AM, Damyan Ivanov wrote: > [Full CC for debiandevel] > > -=| Damyan Ivanov, Mon, May 16, 2011 at 09:12:27PM +0300 |=- >> -=| Ondřej Surý, Mon, May 16, 2011 at 05:27:53PM +0200 |=- >> > Hi Marius, >> > >> > On Mon, May 16, 2011 at 16:39, marius adrian popa wrote: >> > > 2011/5/16 Ondřej Surý : >> > >> Package: firebird2.5 >> > >> Version: 2.5.0.26074-0.ds4 >> > >> Severity: normal >> > >> Tags: patch >> > >> >> > >> Firebird FTBFS on GNU/Hurd because MAXPATHLEN is not defined on that >> > >> platform. >> > >> >> > >> Attached is a patch which fixes that. Please apply, it is a simple >> > >> fix and it blocks php5 build on GNU/Hurd. >> > > >> > > I have commited to svn 2.5 release branch >> > > please test if is ok >> >> That was quick! :) >> >> > Unfortunatelly I am not able to test it as I don't use hurd myself. >> >> I asked the admin of strauss.debian.net (hurd porterbox) to install >> the needed build dependencies for firebird2.5 and will try building it >> there. >> >> > But generally speaking (from my experience of fixing >> > cyrus-imapd-2.x) >> > it should work. I am Ccing debian-hurd list, maybe somebody there >> > could help us with testing. If not I would suggest you go ahead and >> > upload if you have other stuff to release... >> >> I seem to remember a Hurd porter said that there would be problems >> with semaphores or something like that, but I can't find it. Anyway, >> we'll see how the build goes on the porterbox. In the worst case php >> would have to omit the firebird dependency/support for Hurd. > > The build fails with the following error: > > g++ -ggdb -O3 -DNDEBUG -DLINUX -pipe -MMD -fPIC -DFB_SEND_FLAGS=MSG_NOSIGNAL > -I. > ./src/include/gen -I../src/include -I../src/vulcan -DNAMESPACE=Vulcan > -pthread - > g -O2 -DBOOT_BUILD -fno-rtti -c ../src/jrd/gds.cpp -o > ../temp/boot/jrd/gds.o > In file included from ../src/jrd/../jrd/../jrd/ThreadData.h:35, > from ../src/jrd/../jrd/jrd.h:74, > from ../src/jrd/gds.cpp:148: > ../src/jrd/../jrd/../jrd/../common/classes/rwlock.h: In member function 'void > Fi > rebird::RWLock::init()': > ../src/jrd/../jrd/../jrd/../common/classes/rwlock.h:199: error: > 'PTHREAD_RWLOCK_ > PREFER_WRITER_NONRECURSIVE_NP' was not declared in this scope > ../src/jrd/../jrd/../jrd/../common/classes/rwlock.h:199: error: > 'pthread_rwlocka > ttr_setkind_np' was not declared in this scope > make[5]: *** [../temp/boot/jrd/gds.o] Error 1 > > Sending a copy to firebird-devel for oppinion. We need a new define for hurd afther we undefine LINUX that part compiles but i hit another issues that i found it to be in haikuos too g++ -I../src/include/gen -I../src/include -I../src/vulcan -DNAMESPACE=Vulcan -gg db -p -Wall -Wno-switch -DLINUX -pipe -MMD -fPIC -DFB_SEND_FLAGS=MSG_NOSIGNAL -D DEV_BUILD -pthread -DBOOT_BUILD -pthread -fno-rtti -c ../src/jrd/os/posix/isc_ip c.cpp -o ../temp/boot/jrd/isc_ipc.o ../src/jrd/os/posix/isc_ipc.cpp: In function 'bool isc_signal2(int, FPTR_VOID, v oid*, ULONG)': ../src/jrd/os/posix/isc_ipc.cpp:187:31: error: 'SA_SIGINFO' was not declared in this scope ../src/jrd/os/posix/isc_ipc.cpp: In function 'void ISC_signal_cancel(int, FPTR_V OID_PTR, void*)': http://mapopa.blogspot.com/2010/06/firebird-database-porting-progress-on.html ps here is one kvm-linux, qemu image that can be used wget http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz tar -xz < debian-hurd.img.tar.gz kvm -net nic,model=rtl8139 -net user debian-hurd-*.img in my case i didn't had x so kvm -curses -net nic,model=rtl8139 -net user debian-hurd-20110323.img apt-get update && apt-get dist-upgrade apt-buildep firebird2.5 then checkout from svn/debian or git http://mapopa.blogspot.com/2010/09/howto-checkout-firebird-25-release.html tip add --enable-system-icu --enable-debug by default is detected as i686-unknown-gnu0.3 i have exeperimented with some platform defaults but i still need some work and research to do > > > > ___ > pkg-firebird-general mailing list > pkg-firebird-gene...@lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/pkg-firebird-general ___ pkg-firebird-general mailing list pkg-firebird-gene...@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-firebird-general -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation to
Re: [Firebird-devel] Semantics of release
On 17/05/2011 04:05, Alex Peshkoff wrote:
> In FB2.5 yValve did not need any more MT-safeness except provided by
> atomic counters and some helper locks like hanlers' map RwLock.
> Initially I've planned to keep same approach for FB3. But I did not
> review latest Adriano's changes from this POV.
>
I already show you that 2.5 yvalve is not thread safe. Once more.
How do you expect this code to work concurrently?
--
Statement statement = translate(stmt_handle);
statement->checkPrepared();
sqlda_sup::dasup_clause& clause =
statement->das.dasup_clauses[DASUP_CLAUSE_select];
if (clause.dasup_info_len && clause.dasup_info_buf)
{
iterative_sql_info(status,
stmt_handle,
sizeof(describe_select_info),
describe_select_info,
clause.dasup_info_len,
clause.dasup_info_buf,
dialect,
sqlda);
}
--
Accessing same memory, extending internal buffers, etc.
Adriano
PS: There is a paper
(http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf) from Scott
Meyers and Andrei Alexandrescu showing even or volatile usage in base
classes are wrong. Unfortunately it's down.
--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Semantics of release
> Hey Vlad, you already made your excellent job of misrepresent a > technical discussion into personal one. Congratulations. Thanks. Do you have something else to say ? From technical side, please. ... > See, providers was committed a lot of time ago. The implementation of > (only) *reference counting* is still confusing and working in progress, It seems you are the only confused person (oh, i again "made my excelent job") > and the design changed two days ago by private decision, and it even > didn't considered already wrote and committed code. There was no changes in design. There was fix for huge memory leak after (your, btw) change. Regards, Vlad -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Semantics of release
On 17/05/2011 09:13, Alex Peshkoff wrote: > On 05/17/11 16:07, Vlad Khorsun wrote: >>> To support wrong code and solve nothing. With the cost of all this mess, >>> all this otherwise unneeded discussion, all the global/local pool mess. >> ...only emotions and offence... >> Hey Vlad, you already made your excellent job of misrepresent a technical discussion into personal one. Congratulations. > Agreed - nothing except emotions ... > Emotions, really. Feeling bad of developing with a bad implementation and bad design that will never be possible to change. See, providers was committed a lot of time ago. The implementation of (only) *reference counting* is still confusing and working in progress, and the design changed two days ago by private decision, and it even didn't considered already wrote and committed code. Adriano -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Semantics of release
On 05/17/11 16:07, Vlad Khorsun wrote: >> To support wrong code and solve nothing. With the cost of all this mess, >> all this otherwise unneeded discussion, all the global/local pool mess. > ...only emotions and offence... > Agreed - nothing except emotions ... -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Semantics of release
> Speaking about documentation i'd said we must document usage of every > public > interface and specify explicitly how instance is constructed and destroyed. > Well - with this adjustment I can agree with every style. (Though must say that addRef/release pair in our interfaces is already far-far away from how it's used in things like OLE2. Do you want to rename them?) > PS You make me remember MS way to report errors in their DAC's. They have > global > Errors collection and it must be checked after every call of any object. Or > remember > GetLastError. Do you want something similar ? We can remove IStatus parameter > from every method and add > > IStatus* IMaster::getStatus() > > to the master interface. Not sure i like it... Definitely dislike. This looks VERY bad from MT POV. What if one wants to check for errors in the thread distinct from that in which function was called? (I know it looks strange, but we really had such a case with SAS). That's all are errno-like variations, and people used to have problems with errno in MT world, and why should we once again repeat all that steps? -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Semantics of release
>>> the following way - if refCounter> 1, no error happened (later it >>> always means that nothing like system call failed took place). If >>> refCounter == 1 and object has no special dtor, again no error happened. >> If object have no explicit destructor then release must be called, no >> problem. >> > Your words are very incongruent. "Release" releases, and shall be valid > for any objects. Where i said it is not valid ? Current code not disabled it in any way. You can call release event for last reference if you wish. But this is wrong practice and should be avoided. > You broke the IAttachment from external engines, with are only > release-able. They should not be dropped or detached. If you would be more technical it will help to understand characters you wrote here. So far i don't understand what i broke, why IAttachment from external engines are only release-able while IAttachment from y-valve is detach-able (maybe something wrong in external engines ?) and why they should not be dropped or detached. I can guess that *internal attachment* should not be detach'ed but this is perfectly fits "my model" as it was not attach'ed by external engine code. But i can't even guess why *externla attachment* can't be detach'ed... > Making the release an error is like create private destructors. You > could do it, but difficultly you may justify it. If you'll play by proposed rules all will be ok. So far you gave zero technical reasons agains this rules, only emotions and offence. >>> But if we release something like transaction and due to it rollback some >>> job - transaction is released (what can we do?), but error (or may be >>> better warning? not sure...) is reported - job was implicitly rolled back. >> You can kill me, but i don't understand - why do we want to call >> release, >> if good special explicit destructor is present ??? >> >> ... > Why are we adding addRef/release after all? > > To support wrong code and solve nothing. With the cost of all this mess, > all this otherwise unneeded discussion, all the global/local pool mess. ...only emotions and offence... Regards, Vlad -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Semantics of release
On 17/05/2011 08:27, Vlad Khorsun wrote: >> What about the following - we always pass status vector to release(). > I'm sorry but i against it. addRef\release is and well known pair and its > usage also well known. I see no good reason to change it. More, if we > need to change it, then we use it in a wrong way. > ... >> It's not a problem technically - IStatus is not refCounted. We use it in > Call detach() is also not a problem technically, why don't use it when > necessary ? Why we want to replace detach by release ??? > ... >> the following way - if refCounter> 1, no error happened (later it >> always means that nothing like system call failed took place). If >> refCounter == 1 and object has no special dtor, again no error happened. > If object have no explicit destructor then release must be called, no > problem. > Your words are very incongruent. "Release" releases, and shall be valid for any objects. You broke the IAttachment from external engines, with are only release-able. They should not be dropped or detached. Making the release an error is like create private destructors. You could do it, but difficultly you may justify it. >> But if we release something like transaction and due to it rollback some >> job - transaction is released (what can we do?), but error (or may be >> better warning? not sure...) is reported - job was implicitly rolled back. > You can kill me, but i don't understand - why do we want to call release, > if good special explicit destructor is present ??? > > ... Why are we adding addRef/release after all? To support wrong code and solve nothing. With the cost of all this mess, all this otherwise unneeded discussion, all the global/local pool mess. Adriano -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Semantics of release
> What about the following - we always pass status vector to release(). I'm sorry but i against it. addRef\release is and well known pair and its usage also well known. I see no good reason to change it. More, if we need to change it, then we use it in a wrong way. > It's not a problem technically - IStatus is not refCounted. We use it in Call detach() is also not a problem technically, why don't use it when necessary ? Why we want to replace detach by release ??? > the following way - if refCounter > 1, no error happened (later it > always means that nothing like system call failed took place). If > refCounter == 1 and object has no special dtor, again no error happened. If object have no explicit destructor then release must be called, no problem. > But if we release something like transaction and due to it rollback some > job - transaction is released (what can we do?), but error (or may be > better warning? not sure...) is reported - job was implicitly rolled back. You can kill me, but i don't understand - why do we want to call release, if good special explicit destructor is present ??? ... >> Difference between "destoy" and "release" is semantics. I don't know how >> to explain it else. >> > > _I_ understand you. Good. > But not sure it's OK for documentation POV. Speaking about documentation i'd said we must document usage of every public interface and specify explicitly how instance is constructed and destroyed. > Notice - if we add status vector to release, the problem is almost gone. No, please. > We may just say: people, always check error status please. And add - use detach when needed and release in other cases :) Regards, Vlad PS You make me remember MS way to report errors in their DAC's. They have global Errors collection and it must be checked after every call of any object. Or remember GetLastError. Do you want something similar ? We can remove IStatus parameter from every method and add IStatus* IMaster::getStatus() to the master interface. Not sure i like it... -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [pkg-firebird-general] Bug#626931: FTBFS on GNU/Hurd
On 05/17/11 12:19, marius adrian popa wrote: > On Tue, May 17, 2011 at 10:27 AM, Alex Peshkoff wrote: >> On 05/17/11 08:11, Damyan Ivanov wrote: >>> The build fails with the following error: >>> >>> g++ -ggdb -O3 -DNDEBUG -DLINUX -pipe -MMD -fPIC >>> -DFB_SEND_FLAGS=MSG_NOSIGNAL -I. Sorry - I have not noticed at once that this is Hurd. In that case one certainly should not use -DLINUX - there must be new OS and new prefix file for it, where -DHURD will be present. -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-3482) nbackup ctrl-c segfaults and leaves db locked (delta file continues to grow)
nbackup ctrl-c segfaults and leaves db locked (delta file continues to grow) Key: CORE-3482 URL: http://tracker.firebirdsql.org/browse/CORE-3482 Project: Firebird Core Issue Type: Bug Components: Engine, NBACKUP Affects Versions: 2.5.0 Environment: Linux CS Reporter: Vlad Khorsun Priority: Minor The issue is reported by user privately. Seems Alex can confirm it. The priority is minor as unlock database is very simple to do, so this is not an big issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-3481) nbackup segfaults and leaves db locked when not enough free disk space
nbackup segfaults and leaves db locked when not enough free disk space -- Key: CORE-3481 URL: http://tracker.firebirdsql.org/browse/CORE-3481 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 2.5.0 Environment: Linux, CS Reporter: Vlad Khorsun The issue is reported by user privately but i can't nor confirm nor disprove it. Should be reproduced and investigated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [pkg-firebird-general] Bug#626931: FTBFS on GNU/Hurd
On Tue, May 17, 2011 at 10:27 AM, Alex Peshkoff wrote: > On 05/17/11 08:11, Damyan Ivanov wrote: >> >> The build fails with the following error: >> >> g++ -ggdb -O3 -DNDEBUG -DLINUX -pipe -MMD -fPIC -DFB_SEND_FLAGS=MSG_NOSIGNAL >> -I. >> ./src/include/gen -I../src/include -I../src/vulcan -DNAMESPACE=Vulcan >> -pthread - >> g -O2 -DBOOT_BUILD -fno-rtti -c ../src/jrd/gds.cpp -o >> ../temp/boot/jrd/gds.o >> In file included from ../src/jrd/../jrd/../jrd/ThreadData.h:35, >> from ../src/jrd/../jrd/jrd.h:74, >> from ../src/jrd/gds.cpp:148: >> ../src/jrd/../jrd/../jrd/../common/classes/rwlock.h: In member function >> 'void Fi >> rebird::RWLock::init()': >> ../src/jrd/../jrd/../jrd/../common/classes/rwlock.h:199: error: >> 'PTHREAD_RWLOCK_ >> PREFER_WRITER_NONRECURSIVE_NP' was not declared in this scope >> ../src/jrd/../jrd/../jrd/../common/classes/rwlock.h:199: error: >> 'pthread_rwlocka >> ttr_setkind_np' was not declared in this scope >> make[5]: *** [../temp/boot/jrd/gds.o] Error 1 >> >> Sending a copy to firebird-devel for oppinion. > > Certainly, it's not too hard to add ifdef not to call > pthread_rwlockattr_setkind_np() when it's missing. But small detail - > this call is present in the code since 2003! And never caused > compatibility problems on linux. Therefore may be it's worth first of > all to try to understand why does it not build now on Debian? Hurd is a different beast compared to Linux kernel (microkernel vs almost monolithic one) http://www.gnu.org/software/hurd/hurd.html and there are a lots of issues with threading http://www.gnu.org/software/hurd/open_issues/glibc_libpthread_robust_mutexes.html http://www.gnu.org/software/hurd/libpthread.html Here is one debian image to run with with kvm-linux/qemu http://www.gnu.org/software/hurd/hurd/running/debian.html > > > > -- > Achieve unprecedented app performance and reliability > What every C/C++ and Fortran developer should know. > Learn how Intel has extended the reach of its next-generation tools > to help boost performance applications - inlcuding clusters. > http://p.sf.net/sfu/intel-dev2devmay > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel > -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Semantics of release
On 05/17/11 11:41, Vlad Khorsun wrote: >> On 05/16/11 23:47, Vlad Khorsun wrote: On 16/05/2011 14:12, Vlad Khorsun wrote: >> On 16/05/2011 13:33, Vlad Khorsun wrote: >>> So, if code calls attach\release - this is bug, as for me, and i see >>> no reasons >>> to write code in this way intentionally. I consider at as very bad >>> practice as it >>> could lead to the inexpected side effects (such as implicit rollback). >>> >> Now every provider class has a way to "release" with another methods, > Again, "release" it not how object should be finally destroyed. It > is for > additional references *only*. > This is something new you invented. >>> You asked about semantics and i explained how i understand it. If you >>> have >>> something technical against it - show it here and we'll decide what to do. >>> >> Vlad, let's start with the following - why is calling release() to >> remove last reference is bad? > Because it opens a way to make bugs - rolled back work, for example. > >> Currently I see just one reason - error can't be reported. What if we >> find a way to report an error in such case? > What error do you mean ? At previous message you said that release() > could > be called if detach() failed. Do you see a problem if release() also will > fail ? Or > you talk about something else ? > Treat it as enumeration of possible solutions. :) What about the following - we always pass status vector to release(). It's not a problem technically - IStatus is not refCounted. We use it in the following way - if refCounter > 1, no error happened (later it always means that nothing like system call failed took place). If refCounter == 1 and object has no special dtor, again no error happened. But if we release something like transaction and due to it rollback some job - transaction is released (what can we do?), but error (or may be better warning? not sure...) is reported - job was implicitly rolled back. IFirebirdConf and IPluginConf, for example. They're released with release. >>> IPluginConf is not constructed explicitly from the user POV - it is >>> created >>> by the Firebird and passed into user code, see : >>> >>> IPluginFactory::createPlugin(IPluginConfig* factoryParameter), where >>> >>> user is implemented IPluginFactory interface. >>> >>> IFirebirdConf also not constructed by user request as it is obtained >>> via >>> method of IPluginConfig instance passed above : >>> >>> IFirebirdConf* IPluginConfig::getFirebirdConf() >>> >>> If you ask me why attach() and getFirebirdConf() is different - the >>> answer >>> is : by semantics. And by presence explicit "destructor" function. >> Vlad, I'm afraid that this difference is not enough precise... > attach() constructed object for *my private use* and i'm responcible for > *destroying* it after use. > > getFirebirdConf(), in general, could return some *common* object instance > > and i can't destroy it - i just must *release* it after usage. > > Difference between "destoy" and "release" is semantics. I don't know how > to explain it else. > _I_ understand you. But not sure it's OK for documentation POV. Notice - if we add status vector to release, the problem is almost gone. We may just say: people, always check error status please. -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Semantics of release
> On 05/16/11 23:47, Vlad Khorsun wrote: >>> On 16/05/2011 14:12, Vlad Khorsun wrote: > On 16/05/2011 13:33, Vlad Khorsun wrote: >> So, if code calls attach\release - this is bug, as for me, and i see >> no reasons >> to write code in this way intentionally. I consider at as very bad >> practice as it >> could lead to the inexpected side effects (such as implicit rollback). >> > Now every provider class has a way to "release" with another methods, Again, "release" it not how object should be finally destroyed. It is for additional references *only*. >>> This is something new you invented. >> You asked about semantics and i explained how i understand it. If you >> have >> something technical against it - show it here and we'll decide what to do. >> > > Vlad, let's start with the following - why is calling release() to > remove last reference is bad? Because it opens a way to make bugs - rolled back work, for example. > Currently I see just one reason - error can't be reported. What if we > find a way to report an error in such case? What error do you mean ? At previous message you said that release() could be called if detach() failed. Do you see a problem if release() also will fail ? Or you talk about something else ? >>> IFirebirdConf and IPluginConf, for example. They're released with release. >> IPluginConf is not constructed explicitly from the user POV - it is >> created >> by the Firebird and passed into user code, see : >> >> IPluginFactory::createPlugin(IPluginConfig* factoryParameter), where >> >> user is implemented IPluginFactory interface. >> >> IFirebirdConf also not constructed by user request as it is obtained via >> method of IPluginConfig instance passed above : >> >> IFirebirdConf* IPluginConfig::getFirebirdConf() >> >> If you ask me why attach() and getFirebirdConf() is different - the >> answer >> is : by semantics. And by presence explicit "destructor" function. > > Vlad, I'm afraid that this difference is not enough precise... attach() constructed object for *my private use* and i'm responcible for *destroying* it after use. getFirebirdConf(), in general, could return some *common* object instance and i can't destroy it - i just must *release* it after usage. Difference between "destoy" and "release" is semantics. I don't know how to explain it else. >>> The situation with new classes trying to be smart using reference >>> counting is still almost unexplained from the POV of why that was done. >>> >>> Sure you may create artificial and specific examples of where they make >>> things to not crash. >>> >>> But nothing except an atomic counter is currently being cared regard >>> MT-safeness. Y-valve has internal state not synchronized, for example. >>> Y-valve delegates call to another providers, and they do nothing re. >>> died objects to return information. >> This is still work in progress, i think. Probably Alex have better >> answer. > > In FB2.5 yValve did not need any more MT-safeness except provided by > atomic counters and some helper locks like hanlers' map RwLock. > Initially I've planned to keep same approach for FB3. But I did not > review latest Adriano's changes from this POV. I think we still have what to do to make code and interfaces more clear for end users. This is why i said that it is work in progress. Regards, Vlad -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Semantics of release
> On 05/16/11 21:00, Vlad Khorsun wrote: >> >> We can introduce some special mode to report such errors using >> exceptions, >> or write message into log, or even provide callback for debugging purposes. >> >> But Adriano's question was about *semantics*. So, do you agree with me >> that >> explicit detach() must be called by good code and not just release() ? And >> that >> call of release() when refCount == 1 is a bug in caller's code ? > > My initial thinking was - for objects, that have explicit dtor functions > (detach/commit/etc.), explicit dtor() must be called by good code and > not just release(). Here we are agree, ok. > But calling release() with refCount == 1 is not always bug. It's > (logically) like handling errors in dtors - sometimes it's better to > ignore error in dtor cause it can be already called due to another > error. And if some thread needs to tell to the object - I do not need > you any more, I anyway can't handle an error if it happens, why not let > it call release()? As I've already said, logically this does not differ > from lost network connection. It is almost true. Almost, because in the case of unrecoverable error in detach() we must offer *correct* way to release attachment and all underlying objects. For remote interface we have fb_cancel_operation(...fb_cancel_abort...) which forcebly closed connection and (should) allow to free all other handles in usual way. I can't imagine unrecoverable error in, say, statement->drop(), which is not related to the same unrecoverable error in detach(), so forced close of attachment is enough for us. If we have explicit destructor - we *must* use it. Else remove it and use release() always. Is it wrong ? Regards, Vlad -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [pkg-firebird-general] Bug#626931: FTBFS on GNU/Hurd
On 05/17/11 08:11, Damyan Ivanov wrote: > > The build fails with the following error: > > g++ -ggdb -O3 -DNDEBUG -DLINUX -pipe -MMD -fPIC -DFB_SEND_FLAGS=MSG_NOSIGNAL > -I. > ./src/include/gen -I../src/include -I../src/vulcan -DNAMESPACE=Vulcan > -pthread - > g -O2 -DBOOT_BUILD -fno-rtti -c ../src/jrd/gds.cpp -o > ../temp/boot/jrd/gds.o > In file included from ../src/jrd/../jrd/../jrd/ThreadData.h:35, > from ../src/jrd/../jrd/jrd.h:74, > from ../src/jrd/gds.cpp:148: > ../src/jrd/../jrd/../jrd/../common/classes/rwlock.h: In member function 'void > Fi > rebird::RWLock::init()': > ../src/jrd/../jrd/../jrd/../common/classes/rwlock.h:199: error: > 'PTHREAD_RWLOCK_ > PREFER_WRITER_NONRECURSIVE_NP' was not declared in this scope > ../src/jrd/../jrd/../jrd/../common/classes/rwlock.h:199: error: > 'pthread_rwlocka > ttr_setkind_np' was not declared in this scope > make[5]: *** [../temp/boot/jrd/gds.o] Error 1 > > Sending a copy to firebird-devel for oppinion. Certainly, it's not too hard to add ifdef not to call pthread_rwlockattr_setkind_np() when it's missing. But small detail - this call is present in the code since 2003! And never caused compatibility problems on linux. Therefore may be it's worth first of all to try to understand why does it not build now on Debian? -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Semantics of release
On 05/16/11 23:47, Vlad Khorsun wrote: >> On 16/05/2011 14:12, Vlad Khorsun wrote: On 16/05/2011 13:33, Vlad Khorsun wrote: > So, if code calls attach\release - this is bug, as for me, and i see > no reasons > to write code in this way intentionally. I consider at as very bad > practice as it > could lead to the inexpected side effects (such as implicit rollback). > Now every provider class has a way to "release" with another methods, >>> Again, "release" it not how object should be finally destroyed. It is >>> for >>> additional references *only*. >>> >> This is something new you invented. > You asked about semantics and i explained how i understand it. If you have > something technical against it - show it here and we'll decide what to do. > Vlad, let's start with the following - why is calling release() to remove last reference is bad? Currently I see just one reason - error can't be reported. What if we find a way to report an error in such case? >> IFirebirdConf and IPluginConf, for example. They're released with release. > IPluginConf is not constructed explicitly from the user POV - it is > created > by the Firebird and passed into user code, see : > > IPluginFactory::createPlugin(IPluginConfig* factoryParameter), where > > user is implemented IPluginFactory interface. > > IFirebirdConf also not constructed by user request as it is obtained via > method of IPluginConfig instance passed above : > > IFirebirdConf* IPluginConfig::getFirebirdConf() > > If you ask me why attach() and getFirebirdConf() is different - the answer > is : by semantics. And by presence explicit "destructor" function. Vlad, I'm afraid that this difference is not enough precise... > >> The situation with new classes trying to be smart using reference >> counting is still almost unexplained from the POV of why that was done. >> >> Sure you may create artificial and specific examples of where they make >> things to not crash. >> >> But nothing except an atomic counter is currently being cared regard >> MT-safeness. Y-valve has internal state not synchronized, for example. >> Y-valve delegates call to another providers, and they do nothing re. >> died objects to return information. > This is still work in progress, i think. Probably Alex have better answer. In FB2.5 yValve did not need any more MT-safeness except provided by atomic counters and some helper locks like hanlers' map RwLock. Initially I've planned to keep same approach for FB3. But I did not review latest Adriano's changes from this POV. -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
