Thijs van Dien

I've been doing this for a very long time, so surely I can share some experience. Yes, you can use a backup component that employs the built-in service manager. In my case that's TIBOBackupService from IBObjects. The key is that you need to name the output file 'stdout' and have the option to capture that. This component does; I haven't looked into others. Most have similar methods, though. Keep in mind that it produces binary, so I wrote a subclass to handle that: type TIBOBinaryCapableBackupService = class(TIBOBackupService) public function GetNextBinaryChunk: TBytes; end; implementation { TIBOBinaryCapableBackupService } function TIBOBinaryCapableBackupService.GetNextBinaryChunk: TBytes; var LLength: Integer; begin Result := nil; if EOF then Exit; GetNextChunk; // Fill buffer LLength := IB_Session.isc_vax_integer(Pointer(OutputBuffer + 1), 2); SetLength(Result, LLength); Move(OutputBuffer[3], Pointer(Result)^, LLength); end; The alternative is indeed having gbak on the client. Eventually I switched to that, because I wanted to be able to use a newer version (3.0) than the server itself (2.5) – that way I could exclude certain tables. Much of the code was inspired by @David Heffernan in my question here.

The one thing I'm still waiting for is per project packages/components that are automatically (un)loaded by the IDE, right from the code repository they're used in (i.e. machine independent). I can't believe we still don't have something like that after so many years.

So now the DocWiki has been offline again for several days already? Impressive...

If most of all you want to prevent repeated handshakes, that's just a matter of using persistent HTTP connections (keep-alive)...? Another good option could be a RESTful batch API, which in the end helps you optimize more (e.g. database queries). Should you go for the WebSocket idea, the closest thing to a standard is JSON-RPC 2.0, I'd say. There are ready clients available for several languages. Depending on the amount of methods you'll support, consider providing a machine readable spec using OpenRPC.

Looking forward to the PDF version. :)

Offtopic perhaps, but I'd advise you not to put such personal information on the internet like this.

Alright, a library I recently started using more does indeed leave the rounding mode changed sometimes. It's a sad reality, but I'll be (even) more suspicious of third party code and try to make the software increasingly resilient on this front over time. For now, I hope removing a major cause will solve the issues experienced. Thanks!

What would your suggestion be to avoid this situation of (sudden) undesirable results in a big legacy application where I can't just go and change all the code?

Me. 😉 This software has never experienced a problem like this before in over 20 years, so my first impulse is to track down what started causing this mess. I'm just not sure how if it I can't consistently reproduce it. Reading a little bit more about the topic, for example here, makes me rather hopeless about it all. I wonder what the sane approach would be if I want all my "own" rounding to behave like rmNearest. I could replace all calls to Round by a custom function, but that leaves a ton of libraries like FastReport potentially doing the wrong thing. Calling SetRoundMode in a timer is about as ugly as it gets...

Check. I could extend the logging with a call to Get8087CW to see if that's the reason. If it is, how should I go about finding out how it ends up in the 'wrong' state?

(Cross posting from StackOverflow.) I'm facing the bizarre situation that the same program on the same machine doing a Round() of the same floating point value does not always give the same result. At first I thought it has to be glitch because of a bit flip or something, but it keeps on coming back. Now it started to happen on a completely different machine as well. Bad results come up rather rarely, in the order of once a week. When they do, it seems they keep happening until the program is restarted. That might be a coincidence, however. So far, I've been unable to reproduce it at will. This is all happening on the main thread, by the way. A check I consider adding is whether Round keeps pointing to the same memory address. Any other ideas? 2020-12-28 08:30:19.411 DBGrid1.Fields[17].AsString: 0,239999994635582 2020-12-28 08:30:19.411 FloatToStr(DBGrid1.Fields[17].AsFloat): 0,239999994635582 2020-12-28 08:30:19.411 FloatToStr(1000 * DBGrid1.Fields[17].AsFloat): 239,999994635582 2020-12-28 08:30:19.411 IntToStr(Round(1000 * DBGrid1.Fields[17].AsFloat)): 239 2020-12-28 08:30:19.411 FloatToStr(DBGrid1.Fields[17].AsSingle): 0,239999994635582 2020-12-28 08:30:19.411 FloatToStr(1000 * DBGrid1.Fields[17].AsSingle): 239,999994635582 2020-12-28 08:30:19.411 IntToStr(Round(1000 * DBGrid1.Fields[17].AsSingle)): 239 2020-12-28 08:30:19.411 FloatToStr(DBGrid1.Fields[17].AsExtended): 0,239999994635582 2020-12-28 08:30:19.412 FloatToStr(1000 * DBGrid1.Fields[17].AsExtended): 239,999994635582 2020-12-28 08:30:19.412 IntToStr(Round(1000 * DBGrid1.Fields[17].AsExtended)): 239 2020-12-28 08:30:19.412 CurrToStr(DBGrid1.Fields[17].AsCurrency): 0,2399 2020-12-28 08:30:19.412 CurrToStr(1000 * DBGrid1.Fields[17].AsCurrency): 239,9 2020-12-28 08:30:19.412 IntToStr(Round(1000 * DBGrid1.Fields[17].AsCurrency)): 239 2020-12-28 08:30:19.412 FloatToStr(Query1.FieldByName('FIELD').AsFloat): 0,239999994635582 2020-12-28 08:30:19.412 FloatToStr(1000 * Query1.FieldByName('FIELD').AsFloat): 239,999994635582 2020-12-28 08:30:19.412 IntToStr(Round(1000 * Query1.FieldByName('FIELD').AsFloat)): 239 2020-12-28 08:30:19.412 FloatToStr(Query1.FieldByName('FIELD').AsSingle): 0,239999994635582 2020-12-28 08:30:19.412 FloatToStr(1000 * Query1.FieldByName('FIELD').AsSingle): 239,999994635582 2020-12-28 08:30:19.413 IntToStr(Round(1000 * Query1.FieldByName('FIELD').AsSingle)): 239 2020-12-28 08:30:19.413 FloatToStr(Query1.FieldByName('FIELD').AsExtended): 0,239999994635582 2020-12-28 08:30:19.413 FloatToStr(1000 * Query1.FieldByName('FIELD').AsExtended): 239,999994635582 2020-12-28 08:30:19.413 IntToStr(Round(1000 * Query1.FieldByName('FIELD').AsExtended)): 239 2020-12-28 08:30:19.413 CurrToStr(Query1.FieldByName('FIELD').AsCurrency): 0,2399 2020-12-28 08:30:19.413 CurrToStr(1000 * Query1.FieldByName('FIELD').AsCurrency): 239,9 2020-12-28 08:30:19.413 IntToStr(Round(1000 * Query1.FieldByName('FIELD').AsCurrency)): 239 2020-12-28 08:30:19.413 CurrToStr(Query1.FieldByName('FIELD').AsCurrency): 0,2399 2020-12-28 08:30:19.413 CurrToStr(1000 * Query1.FieldByName('FIELD').AsCurrency): 239,9 2020-12-28 08:30:19.413 IntToStr(Round(1000 * Query1.FieldByName('FIELD').AsCurrency)): 239 2020-12-28 08:30:19.414 BinToHex(DBGrid1.Fields[17].AsFloat): 00000000008FC2F5FC3F 2020-12-28 08:40:46.461 DBGrid1.Fields[17].AsString: 0,239999994635582 2020-12-28 08:40:46.462 FloatToStr(DBGrid1.Fields[17].AsFloat): 0,239999994635582 2020-12-28 08:40:46.463 FloatToStr(1000 * DBGrid1.Fields[17].AsFloat): 239,999994635582 2020-12-28 08:40:46.463 IntToStr(Round(1000 * DBGrid1.Fields[17].AsFloat)): 240 2020-12-28 08:40:46.463 FloatToStr(DBGrid1.Fields[17].AsSingle): 0,239999994635582 2020-12-28 08:40:46.463 FloatToStr(1000 * DBGrid1.Fields[17].AsSingle): 239,999994635582 2020-12-28 08:40:46.463 IntToStr(Round(1000 * DBGrid1.Fields[17].AsSingle)): 240 2020-12-28 08:40:46.463 FloatToStr(DBGrid1.Fields[17].AsExtended): 0,239999994635582 2020-12-28 08:40:46.463 FloatToStr(1000 * DBGrid1.Fields[17].AsExtended): 239,999994635582 2020-12-28 08:40:46.463 IntToStr(Round(1000 * DBGrid1.Fields[17].AsExtended)): 240 2020-12-28 08:40:46.463 CurrToStr(DBGrid1.Fields[17].AsCurrency): 0,24 2020-12-28 08:40:46.463 CurrToStr(1000 * DBGrid1.Fields[17].AsCurrency): 240 2020-12-28 08:40:46.463 IntToStr(Round(1000 * DBGrid1.Fields[17].AsCurrency)): 240 2020-12-28 08:40:46.463 FloatToStr(Query1.FieldByName('FIELD').AsFloat): 0,239999994635582 2020-12-28 08:40:46.463 FloatToStr(1000 * Query1.FieldByName('FIELD').AsFloat): 239,999994635582 2020-12-28 08:40:46.463 IntToStr(Round(1000 * Query1.FieldByName('FIELD').AsFloat)): 240 2020-12-28 08:40:46.463 FloatToStr(Query1.FieldByName('FIELD').AsSingle): 0,239999994635582 2020-12-28 08:40:46.464 FloatToStr(1000 * Query1.FieldByName('FIELD').AsSingle): 239,999994635582 2020-12-28 08:40:46.464 IntToStr(Round(1000 * Query1.FieldByName('FIELD').AsSingle)): 240 2020-12-28 08:40:46.464 FloatToStr(Query1.FieldByName('FIELD').AsExtended): 0,239999994635582 2020-12-28 08:40:46.464 FloatToStr(1000 * Query1.FieldByName('FIELD').AsExtended): 239,999994635582 2020-12-28 08:40:46.464 IntToStr(Round(1000 * Query1.FieldByName('FIELD').AsExtended)): 240 2020-12-28 08:40:46.464 CurrToStr(Query1.FieldByName('FIELD').AsCurrency): 0,24 2020-12-28 08:40:46.464 CurrToStr(1000 * Query1.FieldByName('FIELD').AsCurrency): 240 2020-12-28 08:40:46.464 IntToStr(Round(1000 * Query1.FieldByName('FIELD').AsCurrency)): 240 2020-12-28 08:40:46.464 CurrToStr(Query1.FieldByName('FIELD').AsCurrency): 0,24 2020-12-28 08:40:46.464 CurrToStr(1000 * Query1.FieldByName('FIELD').AsCurrency): 240 2020-12-28 08:40:46.465 IntToStr(Round(1000 * Query1.FieldByName('FIELD').AsCurrency)): 240 2020-12-28 08:40:46.465 BinToHex(DBGrid1.Fields[17].AsFloat): 00000000008FC2F5FC3F

So far, I've been recreating my HTTP client (and SSL handler) for every request, because I'm a little paranoid of leftover state that could affect stability and/or correctness. The price I pay for that, is that I can't benefit from keep-alive. What would I have to do to make sure that no previous request has any influence on the (observable) state of TIdHTTP, except for keeping the connection open? Completely erasing the last response (how?) would be a good start, but perhaps there's more I can do to keep state to a minimum, and always start fresh to the extent possible, while being more efficient at the network level.

I am missing the point of this discussion. As has been said, it is impossible to foresee all states the service could end up in. When it appears that things are not working correctly, the priority is to get back into a known good state. Terminating the service and having it restarted by the service manager (Windows) is a means to do so. Yes, it should be logged and investigated later to hopefully prevent it in the future, but some incidents are rare enough that dealing with them in this way is acceptable. If you disagree with that, go tell the Erlang people they got it all wrong. I'm just looking for the best way to implement it. Although I still feel that the stronger isolation of processes might be desirable, for now I am going to count on threads being good enough. Here's how my dead man's switch looks right now: when the service is started, I use CreateTimerQueueTimer with a callback that the worker is supposed to continuously prevent from executing by means of ChangeTimerQueueTimer. If it does go off, that first sets an event to give the main thread (service loop) a chance to log what's happening and exit relatively cleanly. If that doesn't happen within 5 seconds, because apparently it got into a faulty state as well, ExitProcess(1) is called. My assumption is that because this third thread only calls three "cheap" Windows API's (SetEvent, Sleep, and ExitProcess) directly, things would have to be very, very bad for that to fail. And short of some accidental denial of service attack on the thread pool, I can't really think of anything that would keep it from running at all.

If the worker were known to be well-behaved, there would be no need for such monitoring to begin with. There's networking, third party libraries, DLLs and what not. I can't know exactly what could cause a freeze; only that it will be rare, and restarting will be an effective way to get on with life. Sort of the 'Let It Crash' philosophy. I want to treat the worker as a blackbox. The only requirement is it will regularly report that it's still functional, and if it doesn't for too long (because it is stuck for whatever reason) the whole process is to be killed—not just threads.

It is always safe to kill, but that should only happen when it appears no work is being done for too long. As for the cause, I don't want to make any assumptions. In the worker thread, "anything" can happen. Part of my question is whether another thread (with which there is no interaction) is a safe enough place to monitor the worker and potentially kill the whole process, or that I need stronger isolation. Could something nasty happening in one thread cause issues for the whole process (not crashing but effectively blocking it completely)? I don't know; that's why I'm asking. And if so, is a Windows-owned thread acting in the context of that same single process any safer? Again, not familiar enough with Windows internals.