[fpc-devel] Exceptions in threads

[Mattias Gärtner]

Zitat von Marco van de Voort <marcov at stack.nl>:

> 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.

When the exception occurs, the starter is somewhere in the AMethod or in the
wait loop (= somewhere in DoParallel). The starter will eventually come back to
the wait loop where it checks the helper threads. The stacktrace is not that
important, but the type and message of the exception object is.
IMO it would be very helpful, if DoParallel could work with try..except.


> - It assumes some form of polling/synchronization and essentially
> event-driven behaviour.

Yes.


> > > > 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.

Yes, that is an alternative.


> > > (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.

Yes.

Mattias