[Libburn] Handling abort situations with libburn

[scdbackup at gmx.net]

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