Okay, thanks Przemek, I'd say to leave these after 1.0.
Brgds,
Viktor
On 2008.07.26., at 14:41, Przemyslaw Czerpak wrote:
On Sat, 26 Jul 2008, Szakáts Viktor wrote:
Hi Viktor,
* TODO
* Updated.
; QUESTION: Is this still valid?:
Assign to: Przemek
Detail...: Clean RDD code to be safe for return from RT errors
Status...: Open.
Yes it is.
There are two related issues:
1. add protection against freeing RDD AREA from user UDFs and/or
RT error handler.
Now RDDs do not know anything about such situation and may
still try to access AREA members after executing user code.
It's not trivial to add good protection for such situations
which will always work without some speed overhead or serious
modification in RDD API though I have some ideas how to create
small trick which should resolve the problem but I do not want
to touch it now.
2. clean RDD code to be ready for farther execution (usually clean
exit) after some RT errors caused by corrupted files or broken
IO operations. Now it generates internal errors in such case
just after RT ones. The problem is mostly related to DBFCDX.
When I was working on DBFNTX I cleaned to code to play well
in such situations. It's not very complicated job but because
RDD operations are critical if I'll change it now then we will
have to test it very extensively. I also plan to make some
modifications in DBF* index RDDs to avoid duplicate code and
easier adding new index formats. I would like to join modifications
in DBFCDX with this new API and this is yet another reason for
me to not replicate the work.
In summary these are not typical operations and in 99% not critical
for normal code. I think they can be left for the future. AFAIK
Clipper
is also not safe in such situations.
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
