From: Alex P. <pes...@ma...> - 2022-08-25 08:28:03
|
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? |