Marc-André Lureau <marcandre.lur...@gmail.com> writes: > Hi > > On Thu, Oct 20, 2016 at 11:38 AM Daniel P. Berrange <berra...@redhat.com> > wrote: > >> On Wed, Oct 19, 2016 at 07:06:16PM +0100, Dr. David Alan Gilbert wrote: >> > * Daniel P. Berrange (berra...@redhat.com) wrote: [...] >> > > If we make cur_mon a thread-local, then error_report() is equivalent >> > > to fprintf(stderr) for the migration code, since the migration >> > > code runs in a different thread thread, and so would always see >> > > cur_mon == NULL. >> > >> > Yes, that would become safe; it does sound the best fix for the current >> > worry. >> > >> > If we had that, then why not wire up error_report to pass errors back to >> > QMP >> > as well? >> >> You have a problem of context - if you have multiple monitors, how do >> you know which to send the error back to if you're not in the event >> loop thread, and thus cur_mon is NULL. With Marc-Andre's series which >> allows proper async command processing it gets even harder, because >> there's potentially many outstanding commands associated with a monitor >> and you need to decide which the error should be given to. >> > > I would think the contrary, it gets potentially easier as it may actually > keep the associated monitor (the one that triggered the command) with the > 'async' context.
Finding the monitor where the asynchronous command was issued is feasible, but you cannot use it to store an asynchronous command's error, because the currently running command is already using it.
