langc interface and catching exceptions

[prajnoha]

Is the langc interface catching all exceptions and returning them/translating them into TkrzwStatus?

I'm specifically interested in what happens if, for example, the malloc inside an API call fails. I've tried this through gdb quickly, inducing the malloc to return NULL and I got SIGART due to the default exception handling taking place. That is, exception is "unhandled".

Also, I'm interested in what happens if during ProcessMulti (tkrzw_dbm_process_multi in langc API) there's a fail in a processing one record (like that allocation failure) while we're in the middle of the overall processing and there area records already processed successfully. Is the transaction discarded and original values for already processed/edited records put back and new records discarded?

[estraier]

Tkrzw's code doesn't throw any exception by itself unless you don't call OrDie explicitly. And, the langc interface doesn't have any exception handers. Therefore, if malloc failed and the new operator throws an exception, the exception will not be caught, which causes abortion. Whereas writing the "cache" block in each langc functions is a possible workaround, I haven't done it because there's few practical ways to recover from malloc's failure. I'm interested in what other people think about this issue. By default, any updating operations of Tkrzw including ProcessMulti could result in data loss and inconsistency if the process crashes during the operation. Meanwhile, you can configure it for ACID properties of transactions. Please take a look at these sections in the document. https://dbmx.net/tkrzw/#tips_restore https://dbmx.net/tkrzw/#tips_acid

…

On Tue, Feb 15, 2022 at 6:43 PM Peter Rajnoha ***@***.***> wrote: Is the langc interface catching all exceptions and returning them/translating them into TkrzwStatus? I'm specifically interested in what happens if, for example, the malloc inside an API call fails. I've tried this through gdb quickly, inducing the malloc to return NULL and I got SIGART due to the default exception handling taking place. That is, exception is "unhandled". Also, I'm interested in what happens if during ProcessMulti ( tkrzw_dbm_process_multi in langc API) there's a fail in a processing one record (like that allocation failure) while we're in the middle of the overall processing and there area records already processed successfully. Is the transaction discarded and original values for already processed/edited records put back and new records discarded? — Reply to this email directly, view it on GitHub <#27>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQGJVRHILQWN5UFIVR3ES3LU3IN3ZANCNFSM5ON6YV5Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[estraier]

Oh, I should have written "*catch*" not "cache".

…

On Tue, Feb 15, 2022 at 8:57 PM Mikio Hirabayashi ***@***.***> wrote: Tkrzw's code doesn't throw any exception by itself unless you don't call OrDie explicitly. And, the langc interface doesn't have any exception handers. Therefore, if malloc failed and the new operator throws an exception, the exception will not be caught, which causes abortion. Whereas writing the "cache" block in each langc functions is a possible workaround, I haven't done it because there's few practical ways to recover from malloc's failure. I'm interested in what other people think about this issue. By default, any updating operations of Tkrzw including ProcessMulti could result in data loss and inconsistency if the process crashes during the operation. Meanwhile, you can configure it for ACID properties of transactions. Please take a look at these sections in the document. https://dbmx.net/tkrzw/#tips_restore https://dbmx.net/tkrzw/#tips_acid On Tue, Feb 15, 2022 at 6:43 PM Peter Rajnoha ***@***.***> wrote: > Is the langc interface catching all exceptions and returning > them/translating them into TkrzwStatus? > > I'm specifically interested in what happens if, for example, the malloc > inside an API call fails. I've tried this through gdb quickly, inducing the > malloc to return NULL and I got SIGART due to the default exception > handling taking place. That is, exception is "unhandled". > > Also, I'm interested in what happens if during ProcessMulti ( > tkrzw_dbm_process_multi in langc API) there's a fail in a processing one > record (like that allocation failure) while we're in the middle of the > overall processing and there area records already processed successfully. > Is the transaction discarded and original values for already > processed/edited records put back and new records discarded? > > — > Reply to this email directly, view it on GitHub > <#27>, or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AQGJVRHILQWN5UFIVR3ES3LU3IN3ZANCNFSM5ON6YV5Q> > . > Triage notifications on the go with GitHub Mobile for iOS > <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> > or Android > <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. > > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >

[prajnoha]

Whereas writing the "cache" block in each langc functions is a possible workaround, I haven't done it because there's few practical ways to recover from malloc's failure.

By default, any updating operations of Tkrzw including ProcessMulti could result in data loss and inconsistency if the process crashes during the operation. Meanwhile, you can configure it for ACID properties of transactions. Please take a look at these sections in the document. https://dbmx.net/tkrzw/#tips_restore https://dbmx.net/tkrzw/#tips_acid

For that, I'd need to write the database to a file. I don't actually mind if the database is not durable enough and I'm counting only with in-memory database use. If anything fails, I can just throw away all the existing database and recreate it quite easily. For that, it would be great if we had a way to detect this condition so I can act appropriately. Receiving SIGABRT is just very rough for that. In general, the SIGABRT may have different reasons/sources so it's harder to detect that it comes exactly because the malloc inside a library failed. Getting proper return value in all failure cases (including the failed malloc) would be of great help here.

[estraier]

I think your suggestion is reasonable so I'll write catch blocks to return error values. Anyway, one typical headache with error handling of memory allocation failures is that the handler cannot do anything which might cause memory allocation. :(

…

On Tue, Feb 15, 2022 at 9:27 PM Peter Rajnoha ***@***.***> wrote: Whereas writing the "cache" block in each langc functions is a possible workaround, I haven't done it because there's few practical ways to recover from malloc's failure. By default, any updating operations of Tkrzw including ProcessMulti could result in data loss and inconsistency if the process crashes during the operation. Meanwhile, you can configure it for ACID properties of transactions. Please take a look at these sections in the document. https://dbmx.net/tkrzw/#tips_restore https://dbmx.net/tkrzw/#tips_acid For that, I'd need to write the database to a file. I don't actually mind if the database is not durable enough and I'm counting only with in-memory database use. If anything fails, I can just throw away all the existing database and recreate it quite easily. For that, it would be great if we had a way to detect this condition so I can act appropriately. Receiving SIGABRT is just very rough for that. In general, the SIGABRT may have different reasons/sources so it's harder to detect that it comes exactly because the malloc inside a library failed. Getting proper return value in all failure cases (including the failed malloc) would be of great help here. — Reply to this email directly, view it on GitHub <#27 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQGJVRHYCRVBYZYLE7A4AZTU3JBDTANCNFSM5ON6YV5Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[estraier]

I modified the C interface and released 1.0.23.
Now, every function of the C interface is guarded by the catch block and returns false/null/0 when exceptions are thrown.

[prajnoha]

Great! Thank you!