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