On 8/24/22 20:59, Dimitry Sibiryakov wrote:
Alexander Peshkov wrote 24.08.2022 19:06:
On 8/24/22 14:31, Dimitry Sibiryakov wrote:
 > Without it services seem to be pretty useless.

I think this to be suggested in devel and if nobody sees problems - feel
free to add a ticket, I will implement it.

  Ok. But I don't think that a simple hack returning only thread exit code is a right way to go.

If I was thinking that way that feature could be present since 2. 5 :-)


Notice - in status vector it will be a notice that service thread failed
with exit code NNN, original message with a reason for is unknown at the
final point.

  It is not quite try.
  In the old dark days when the service thread just run an external utility and mindlessly redirect whole output to the client it was so. But nowadays the thread is doing whole work itself

Just small notice - an ability to return errors in SV does not directly depend upon does service run as a process or as a thread. It's possible to pass SV cross-process but nobody cared about. With service threads pre-2.5 it was a mix - some errors were returned as SV, some - as text lines.

so it can return a proper errors, warnings and verbose messages through isc_svc_query() as soon as they happen.

But here are some problems:
- An error when querying service is treated by 99% of callers (starting with fbsvcmgr) as fatal one. Other errors will not be displayed. - What about warnings - yes, they probably may be used at the first glance. But once again big problems with old clients. What should return isc_service_query - success or failure? On failure one prints status and detachs from service, on success - ignores SV.
- Verbose messages are already passed through isc_svc_query().

Certainly we may require analyzing warnings from clients who want to receive verbose messages in machine-readable form. Is it what you want?




Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to