[Libburn] Handling abort situations with libburn

[Derek Foreman]

Wow, I'm going to have to plead guilty on this one.

The only time I check if the burn was cancelled is during the flush at the 
end.

So, you'll run almost a complete burn time, then turn it into a coaster at 
the last second.

The fix shouldn't take much brain time.  Might take a little wall clock 
time.

Thomas, are you keeping a running list of all the problems you've found? 
A repost would save me some sorting through the mess I laughingly call my 
mailbox. :/

On Wed, 25 Jan 2006, scdbackup at gmx.net wrote:

> Hi,
>
> have a report about my adventures with signal handling.
>
> I did this with SuSE 7.2 (2.4.4) and RIP-14.4 (2.6.14)
> on a LITE-ON LTR48125S. Appropriately as /dev/sg1 resp.
> /dev/hdc. With SuSE 9.0 (2.4.21) it was a LG GSA-4082B
> via /dev/sg0.
> The results are about the same on all systems:
> - Ctrl+C needs to be handled.
> - burn_drive_cancel() does not really seem to work.
> - An emergency abort and unlock command is needed.
>
> I have worked on the first topic with some success
> but am not capable to cope with the other two.
>
> ------------------------------------------------------------
>
> The call burn_drive_cancel() like in
>
>  if(drive_status==BURN_DRIVE_WRITING || drive_status==BURN_DRIVE_READING) {
>    fprintf(stderr,"cdrskin: ABORT : trying to cancel drive operation.\n");
>    burn_drive_cancel(skin->grabbed_drive);
>
> seems not to have any effect. (drive_status is actually 3.)
> This is independent of signals as i can reproduce it
> by a deliberate call of the signal handler, and thus of
> burn_drive_cancel(), from the cdrskin thread which watches
> the burn progress.
> I am burning in SAO mode.
>
> The best thing which i can do is to close the outlet
> of my fifo so that the inlet of libburn produces an
> early EOF and the libburn thread is filling up the
> track with zeros. Then i wait and send appeasing messages
> to the user. (They could be more appeasing, though.)
>
> If cdrskin does not wait for drive status 0 but exits
> then it leaves the drive locked and busy. Virtually
> forever.
> The least dramatic remedy known to me is then
>  cdrecord dev=0,0,0 -abort
> So it is better to block any further signals (which seems
> to be the default, anyway). At least i do not need cdrecord
> that way.
>
> "Better" does not imply "good" in this case, i fear.
>> From the standpoint of the user it would be preferrable if
> an aborted burn run would stop within a shorter time.
> Especially if bash has killed all processes surrounding
> cdrskin and happily displays a shell prompt between
> the messages of surviving cdrskin.
>
>
> (I still did not try how good or bad cdrecord stands
> the same external disturbances. There are discoveries
> for which i am not curious enough.)
>
> ------------------------------------------------------------
>
> The multithreading problems are now neutralized since
> i let my signal handler return immediately on any call
> which has not the pid of the cdrskin thread. I have no
> idea about the further fate of the one libburn thread which
> calls the handler. It stays visible in the process list as
> long as the other two are running. The third thread seems
> not to react on signals. (I suppose it's the one which does
> not react on burn_drive_cancel() either.)
>
> ------------------------------------------------------------
>
> It looks like libburn could need a call that does about
> the same as  cdrecord -abort .
> Not necessarily as a normal replacement for burn_drive_cancel()
> but at least for emergency situations when the drive is
> stuck. (There is still  kill -9  at the user's hand which
> cdrskin cannot ignore.)
>
> ------------------------------------------------------------
>
> The tests may be replayed with
>  http://scdbackup.sourceforge.net/cdrskin-0.1.1.0.2.ts.tar.gz
> (version time stamp of 2006.01.25.144746 or newer).
> Just burn some .iso file and press CTRL+C while the cdrecord-style
> progress messages are indicating that MBs are being written.
>
> There are some documented and some undocumented options of
> cdrskin for the abort situation. They are mutally exclusive:
>
> Default behavior is --abort_handler.
>
> --ignore_signals  sets SIG_IGN handlers so that cdrskin cannot
> be stopped unless it is killed by a non-catchable signal.
> User-thumb-safe but somewhat system-dangerous, i'd say.
> This option is documented and will stay.
>
> --abort_handler installs a signal handler which returns for callers
> which do not have the getpid() of the thread which created the
> CdrskiN boss object. For the owner of the boss object it
> explicitely sets the signal handling to SIG_IGN early in the course
> of handling the first signal.
> Then it tries to perform burn cancelling, drive release and library
> finish. Then it exits.
> Since it closes the fifo outlet (connectect to libburn's inlet)
> the waiting time is not endless any more but about the remaining
> normal writing time of the track. :-/
> This option is documented and will stay.
>
> --abort_handler_neutral is like --abort_handler but does not
> explicitely set the signal handling to SIG_IGN in the course of
> the handling of the first signal.
> There is no visible difference to --abort_handler but i have
> seen enough Unixes where signal handling was not so predictable.
>
> --abort_handler_soft  is like --abort_handler but sets the signal
> handling to default during the handling of the first signal.
> This allows to abort the handler, which is not a good idea
> because then you end up in the --no_abort_handler situation.
>
> --no_abort_handler  does not install any signal handler
> With the LITE-ON this leads to a locked, busy burner with the light
> orange LED color telling me that buffer underrun protection is
> waiting for data. The LG blinks greenly which does not tell more
> than that it is busy.
> cdrecord -abort  is needed for both.
> This option is documented and will stay.
>
> --burnloop_abort_handler does the same as --abort_handler_neutral
> but installs the signal handler only after the call burn_disc_write().
> This does not show a difference to --abort_handler, though. There are
> still two of three threads reacting on the signal and calling cdrskin's
> handler function.
>
>
> Combinable with any of above options:
>
> abort_after_bytecount=N  causes the call of the abort handler
> function after the given amount of bytes is written. This reveils
> that my disappointing result with  burn_drive_cancel()  is not due
> to signals.
>
> ------------------------------------------------------------
>
>
> Have a nice day :)
>
> Thomas
>
> _______________________________________________
> libburn mailing list
> libburn at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libburn
>