[fpc-devel] Exceptions in threads

[Marco van de Voort]

In our previous episode, Mattias Gärtner said:
> > > What should happen when an exception occurs?
> >
> > AFAIK any unhandled exception in a thread will cause it to silently die
> 
> Yes, and that should never happen. At least not for normal exceptions like out
> of memory, index out of bounds, io error - anything that does not corrupt the
> heap.
> I'm catching any exception. But somehow the exception must be delegated to the
> group's starter thread. (which is not necessarily the process' main thread).

I do not get this? Why is this so logical to route this to the starters
thread? 

There are two problems with that:
- the starter thread can be pretty much everywhere in its codepath. Not
necessarily the place where the thread was started.
- It assumes some form of polling/synchronization and essentially
event-driven behaviour.

> > > It would be nice if the exception can be transfered to the main thread.
> > > Is this possible? How?
> >
> > I don't know, set a flag in the thread and check it periodically from
> > the main thread?
> 
> I do that already.
> My current idea is to simply pass the exception object to the other thread and
> raise it there. But I'm not sure if this works always. Maybe I have to set some
> more RTL values to do that cleanly.

More logically, have a tthread.onexception that can handle the exception, if
not already there. It can then pass it to whatever thread or subsystem
necessary using custom synchronization.
 
> > (Florian's suggestion does the reverse: raise in a thread an exception
> > occurred while executing in the context of the main thread)
> 
> Yes, but 'synchronize' is only for the process' main thread.

Yes, and that might not be event-driven either (that is not a requirement
for using tthread, only for synchronization), so IMHO that is false, and
never should be default behaviour.