CVS difference for ais/ai-10266.txt

Differences between 1.3 and version 1.4
Log of other versions for file ais/ai-10266.txt

--- ais/ai-10266.txt	2002/06/14 23:48:56	1.3
+++ ais/ai-10266.txt	2002/07/23 01:05:25	1.4
@@ -1459,3 +1459,148 @@
 
 ****************************************************************
 
+From: Robert Dewar
+Sent: Saturday, June 22, 2002   5:29 AM
+
+> What happens frequently is that Storage_Error is raised when Tsk's stack is
+> exhausted; then the "others" handler is executed, but the call on Text_IO
+> (which  is accomplished by the task, thus using the task's stack) raises
+> Storage_Error again. This second raising causes the tasks to terminate
+> silently anyway, and no message is output. The program deadlocks, and the
+> user then thinks that there is something wrong with the compiler and calls
+> us up.
+
+This seems a bit of a strawman to me. Any reasonable Ada compiler must have
+an option or mechanism for treating unhandled exceptions in tasks as fatal.
+
+****************************************************************
+
+From: Robert Eachus
+Sent: Saturday, June 22, 2002  11:48 AM
+
+I don't see how that would help here.  This is an instance of why Dave
+Emery calls Storage_Error a parachute that opens on impact.  If the
+programmer is aware of the possibility that Storage_Error will occur in
+the task, he can install an error handler that doesn't use Text_IO, or
+that aborts the main program.  But any exception handler invocation
+could cause a new Storage_Error, even if the handler did nothing.  A
+mechanism that aborts the program and prints a message if entering an
+exception handler causes an error is better than nothing, but it will
+not catch this case.  Here it is a call within the error handler that is
+causing the second (unhandled) error, and the user is right to regard it
+as a bug--even if it is actually a language bug not a compiler bug.
+
+The real solution is to have the stack size for Storage_Error handlers
+larger than the stack size for the task.  Maybe a better wording is to
+reserve a possibly user specified area at the end the stack so that the
+first Storage_Error instance can be handled successfully.  To do this
+right of course, the effective stack size has to increase for everything
+called inside the handler.  More elegant, but not strictly necessary is
+for the stack size to revert to its original value when the handler is left.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, June 22, 2002  12:03 PM
+
+> I don't see how that would help here.  This is an instance of why Dave
+> Emery calls Storage_Error a parachute that opens on impact.  If the
+> programmer is aware of the possibility that Storage_Error will occur in
+> the task, he can install an error handler that doesn't use Text_IO, or
+> that aborts the main program.  But any exception handler invocation
+> could cause a new Storage_Error, even if the handler did nothing.  A
+> mechanism that aborts the program and prints a message if entering an
+> exception handler causes an error is better than nothing, but it will
+> not catch this case.  Here it is a call within the error handler that is
+> causing the second (unhandled) error, and the user is right to regard it
+> as a bug--even if it is actually a language bug not a compiler bug.
+
+Sorry I do not see what you are talking about. The problem we have is with
+tasks that go away silently (see the thread, and you will see that this was
+Randy's concern). The option to regard an unhandled exception in a task as
+fatal is exactly what is needed here.
+
+>
+> The real solution is to have the stack size for Storage_Error handlers
+> larger than the stack size for the task.  Maybe a better wording is to
+> reserve a possibly user specified area at the end the stack so that the
+> first Storage_Error instance can be handled successfully.  To do this
+> right of course, the effective stack size has to increase for everything
+> called inside the handler.  More elegant, but not strictly necessary is
+> for the stack size to revert to its original value when the handler is left.
+
+Yes, of course this is the solution. And it is typically how things are done
+
+****************************************************************
+
+From: Ted Baker
+Sent: Monday, June 24, 2002  6:45 AM
+
+This discussion seems to be diverging.  I see you taking about two different
+things:
+
+1) How to arrange, with 100% reliability, that a task cannot die without
+   any notification.
+
+2) How to arrange for a task to perform its own notification of termination,
+   by finalization, exception handling, or whatever.
+
+It is pretty clear to me that any recovery mechanism that requires
+the notification be done by the task that is dying will be subject to some
+possibility that the task dies before it can report its own death.
+
+The discussion of Storage_Error seems to be just searching around
+for one such example of task termination without possibility of
+self-reporting termination.  I'm not sure it matters whether we
+all agree that recovery from stack overflow (enough to execute
+a termination hander/finalizer) can be guaranteed 100%, since there
+always is the possiblity of an unforeseen problem killing a task
+abruptly.
+
+There seems to be no doubt that you will be more reliability if the
+notification mechanism does not rely on the terminated task being
+able to do the notification.
+
+PS:  With the original FSUthreads Gnat runtime (I'm
+not up to date on changes in the past few years) the FSU threads
+library protected a page or two of memory at the end of the task
+stack, and released those pages for temporary use to recover from
+stack overflow.  However, there was still no guarantee that those
+few pages would be enough to execute an arbitrary user-provided
+handle, but if one knew the size of the handler the number of
+reserved pages could be adjusted to allow it to run.
+
+****************************************************************
+
+From: Robert Eachus
+Sent: Friday, June 28, 2002  7:27 PM
+
+> It is pretty clear to me that any recovery mechanism that requires
+> the notification be done by the task that is dying will be subject to some
+> possibility that the task dies before it can report its own death.
+
+I agree.  The need is to solve both problems.  I think I would like to
+see implementations encouraged to raise Program_Error in the main
+program if the run-time routine for raising Storage_Error fails.  If
+Storage_Error is correctly raised and handled silently by a task, well
+that is the way the language works.  This would only deal with cases
+where the run-time code can't execute correctly, which sounds erroneous
+to me.  (You take a trap for an allocation, and the stack pointer is
+iout of range.)  So for example if you had a handler for Storage_Error
+that caused another Storage_Error, you could at least use the debugger.
+
+For the normal case, having some "extra" stack space that is only
+available inside Storage_Error handlers again is the right
+implementation but can't be adequately defined by the language standard.
+
+In my opinion an implementation such as I described is legal, and
+useful.  Anyone writing critical code that can raise Storage_Error needs
+to test the handler under worst case conditions, so the Program_Error
+should only occur during testing in such applications.  (From a testing
+standpoint, you want to see that an object of size k gets allocated
+correctly, an object of size k+1 raises Storage_Error, and allocating an
+object of size k safely followed by another allocation is also raises
+Storage_Error and is correctly handled.)
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent