[Libburn] Re: Cancelling an ongoing burn. Is this dangerous ?

[scdbackup at gmx.net]

Hi,

>>   if(d->cancel)
>>     return;
>
> This looks ok to me.
> 
> You'll probably want to add one of those ifs to the loop in 
> burn_write_leadout too.  That should cut down on the pause by a bit.

Hm ... no, it didn't.

I inserted  return; or  break; but the abort waiting
time was still 12, 13, and 13 seconds in three tests.
Abort was done after the first few MB had been written.

I inserted a fprintf(stderr,) and found out that
the function is not reached if i abort during
 burn_write_track() . 

... it actually is never reached even if the burn
is allowed to complete without any disturbance. 

My burn procedure is still quite the same as in
test/burniso.c .
Did i miss a call which enables lead-out ?


> I think I've fixed cancel in cvs.  It's not exactly tested though. :)
> 
> I'll do that as soon as I have more time.

I would like to bring our libburn versions together
again. But if i now port my two essential patches to the
CVS version then this effort will soon be obsoleted by
your next changes.


Proposal:

Let me do that testing for you.

If you would decide about the API of my enhancements then i
would try to implement them for you into the CVS version and
submit patches which hopefully can be integrated without much
effort on your side.


For that i would need the prototype of the new burn_source
constructor, which takes an fd and a size, like

  struct burn_source *burn_fd_source_new(int fd, off_t size);

This would be implemented by adapting my patch from december.
The patch seems straightforward to me. It is well tested
meanwhile. About 300 CDs burned by using stdin as track source.


Plus the prototype of the single drive "scan" function, like

  int burn_drive_scan_single(struct burn_drive_info **drive,
                             char *deviceadr);

I would implement it on top of a whitelist which is not
a part of the public API. You will then be free to choose
a different implementation as soon as you have some time
for it. The whitelist technology is designed to be harmless.
It is tested with about 200 successful burn runs, a similar
number of separate blank runs, and about 50 runs where a
full unrestricted drive scan was desired.

If you agree to give the resulting patch a try to enter the CVS
then i would begin to work on it.
A short statement about that would be welcome.

My current list of CVS things to test is:
- read-only drives
- padding
- cancel
What i believe is not repaired yet:
- eject
- the need to initialize-shutdown-initialize library and drive
  in order to get correct maximum speed of the inserted media
- catch 22 with abort during  burn_drive_grab()  where the drive
  is not grabbed enough to be released and not released enough
  to be left behind.


Have a nice day :)

Thomas