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

[Derek Foreman]

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.

On Wed, 8 Feb 2006, Derek Foreman wrote:

>
> 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.
>
> As long as d->sync_cache(d) gets called at the end, the drive will stop 
> waiting for more data.
>
>
> I think my fix for this is going to be a little different.
> I'm going to make d->cancel() and d->cancelled() functions that do the proper 
> mutex dance this code is currently lacking completely.
>
> Then I'm going to make the d->write() function return a failure when the 
> drive is in the cancelled state.
>
> Then I'm going to add some missing error handling stuff.
>
> whee.
>
> On Wed, 8 Feb 2006, Thomas Schmitt wrote:
>
>>  Hi,
>>
>>  impatient as i am, i inserted into libburn/write.c:burn_write_track()
>>  a few
>>   if(d->cancel)
>>     return;
>>
>>  This seems to work fine.
>>  The drive becomes BURN_DRIVE_IDLE within a few seconds (15 max).
>>  One can eject it by its own eject-button.
>>  One can successfully write a CD-RW afterwards.
>> 
>>
>>  Derek, could you please have a short look at the attached function
>>  from libburn-0.2 (with four inserted if-return statements) wether
>>  there is any danger involved ?
>>  If you see a potential problem, please let me know and i will
>>  switch back to the old state.
>>
>>  (This is not meant as a patch because it was done quite mindless
>>  under the assumption that one simply has to stop processing sectors.)
>> 
>>
>>  Have a nice day :)
>>
>>  Thomas
>>
>>  --
>>  10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
>>  +++ GMX - die erste Adresse für Mail, Message, More +++
>