On 02/07/15 16:41, Dmitry Yemanov wrote:
> 07.02.2015 13:27, Alex Peshkoff wrote:
>> I do not see too big trouble with full checks of string args. But what
>> about keeping legacy dup check present in ERR_post()? Taking into an
>> account that string once made permanent will remain the same per thread
>> suppose it will be enough for most cases.
> What if the same exception will be made permanent twice, at different
> places? String pointers will be different, but their contents the same.
>
> And even the easy check costs us a performance penalty as
> stuff_exception() is often called 3-5 times during the stack unwinding.
> This wasn't the case with ERR_post().
Stack unwinding itself is a big performance penalty. Certainly that
penalty is implementation dependent, and we can't be absolutely sure
that it will remain CPU-consuming task forever. But today's
implementation in ELF systems is using rather complex tables lookups to
unwind (this way saving resources in normal control flow case) and looks
like comparing 2 status vectors even with strcmp() for strings is very
small overhead compared with unwinding itself. So suppose we may agree
that ...
> That said, stack unwinding is not a performance critical part, so maybe
> we can live with that. But see below.
>> I think that merging errors in stuffException() is both simpler and more
>> efficient.
> Merging errors into tdbb_status_vector is not enough. It leads
> tdbb_status_vector to keep {A, B}, but only either A or B will be
> thrown. This is not how ERR_*() routines work, as they always throw the
> whole tdbb_status_vector. Also, JRD's transliterateException()
> completely ignores tdbb_status_vector and returns only the catched
> exception. Ideally, stuff_exception() should also reset the exception
> object with the merged vector to ensure that the active exception is in
> sync with tdbb_status_vector. It's doable if ex is status_exception but
> e.g. BadAlloc has no status vector inside.
>
> Finally, it opens gates for undesired items to unexpectedly appear
> inside the status vector (current behavior or stuff_exception() hides
> that). This is not bad per se, as it allows us to find and fix such
> cases. But I'd rather avoid such side effects at the Beta stage.
>
What prevents us from emulating ERR_post() behavior when raising exception?
I know one technical issue - error are raised not only inside engine,
and tdbb_status_vector may just not exist.
But it's absolutely the same as for stuff_exception() with merge.
The second problem is BadAlloc. May be we should learn it to have status
vector inside?
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
