Alan.Bateman at Sun.COM
Mon Oct 26 06:00:25 PDT 2009
John Hendrikx wrote:
> Alan Bateman wrote:
>>> - Sometimes the feedback has the same values for several calls in a
>>> row (due to some OS filesystem contention I'm pretty sure). This is
>>> good as it allows me to abort at any time.
>> Right, this is likely wait for I/O or the network (or in theory a
>> sampling glitch as the transfer progress is sampled without
>> synchronization - if an out-of-range value is sampled then it is
>> dropped and the previous "good" value is reported to the progress
> You mean a long is read without synchronization? :)
Yep - it's just a prototype and there isn't any synchronization between
the native code and the thread that is sampling and reporting events
(the sampler simply checks that the value hasn't decreased and is in
range so in theory it might jump forward more that it should - probably
not a big deal for this usage).
> Something I forgot to mention, the cancellation results in a
> FileSystemException being thrown. I think a more specific exception
> or just a true/false return might be helpful. Currently the caller
> code just catches this exception, and then checks if it was an abort
> that caused it (in which case it is ignored) and otherwise rethrows it.
> I can't however really be 100% sure if it was an abort (ie, whether
> the abort triggered from the callback was actually processed) or if
> some other kind of abnormal termination occured.
An exception during recovery doesn't suppress the original abort/cancel
exception but a more specific exception would make this clearer.
> I gave the discontinuing of the events after "false" has been returned
> some more thought, and I think it is probably better to keep sending
> events so even during the clean-up phase it is possible to give
> feedback. My own specific implementation doesn't require it, but
> other implementations may find it useful.
> Another thing I found while I was testing this code is that it doesn't
> eliminate the need for a function to copy attributes. Even though
> copyTo can do this for files, I still need a custom implementation for
> softlinks and directories (unless of course, copyTo also works for
> these kinds of objects... I'll admit that I haven't even considered
> testing this yet, but the javadoc seems to indicate it isn't
> allowed). A suggestion could be to make copyTo work with
> directories/softlinks as well (not recursively), or expose a function
> to copy attributes.
The copyTo method follow sym links by default but it will copy a sym
link if you specify the NOFOLLOW_LINKS option. The file attributes of
sym links aren't usually interesting but our implementation does
whatever is appropriate for the platform. The copyTo method will copy a
That's for playing with this.
More information about the nio-dev