You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's something that has been bothering me for a while, debugging the project and going back and forth between the Kotlin and C++. When, for some reason, the data in the shared buffer are not valid, the module is going to throw an error. The error is often things like the number of arguments not matching, or the type of the variable not being the expected one, etc....
The issue with that approach is that those errors are often thrown before rewind() is called, leaving the buffer cursor is an invalid position instead of going back to 0.
The consequence of that is that once you have got a first sharedbuffer error, it's going to cascade into all the next calls throwing errors as well because the cursor was never reset and so the data is incorrectly read. It makes the logs full of irrelevant messages, making it harder to decipher.
I propose to change all the TransferContext methods so rewind() is now called at the beginning of each call. It shouldn't alter the regular behavior of the ShareBuffer and would also allow the module to "recover" after an error. The only difference would be that the Sharedbuffer is always left at a non-zero position after being used. But I don't think there should be any issue, as the next method using the buffer should reset it anyway.
It's a simple change, only meant to make the module a bit easier to debug, by removing noises after a first error.
The text was updated successfully, but these errors were encountered:
It's something that has been bothering me for a while, debugging the project and going back and forth between the Kotlin and C++. When, for some reason, the data in the shared buffer are not valid, the module is going to throw an error. The error is often things like the number of arguments not matching, or the type of the variable not being the expected one, etc....
The issue with that approach is that those errors are often thrown before
rewind()
is called, leaving the buffer cursor is an invalid position instead of going back to 0.The consequence of that is that once you have got a first sharedbuffer error, it's going to cascade into all the next calls throwing errors as well because the cursor was never reset and so the data is incorrectly read. It makes the logs full of irrelevant messages, making it harder to decipher.
I propose to change all the TransferContext methods so
rewind()
is now called at the beginning of each call. It shouldn't alter the regular behavior of the ShareBuffer and would also allow the module to "recover" after an error. The only difference would be that the Sharedbuffer is always left at a non-zero position after being used. But I don't think there should be any issue, as the next method using the buffer should reset it anyway.It's a simple change, only meant to make the module a bit easier to debug, by removing noises after a first error.
The text was updated successfully, but these errors were encountered: