Jump to content

Thijs van Dien

  • Content Count

  • Joined

  • Last visited

Community Reputation

4 Neutral

Technical Information

  • Delphi-Version
    Delphi 2010

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thijs van Dien

    Automatically killing a service when stuck

    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.
  2. Thijs van Dien

    Automatically killing a service when stuck

    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.
  3. Thijs van Dien

    Automatically killing a service when stuck

    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.
  4. Thijs van Dien

    Automatically killing a service when stuck

    @Lars Fosdal The issue isn't really the restarting itself, but making sure nothing (except for continued operation) will stop that code from running.
  5. Thijs van Dien

    Automatically killing a service when stuck

    Thank you for the surprisingly large number of responses so far. To clarify: my intention in every case is to let Windows restart the service, so cleaning up after handles and all should not be an issue. What I'm looking for, is the simplest solution that can be depended on to get that done. Using child processes for all the work means quite a big refactoring that I'm willing to do only if it is actually more robust than 1 or 4 (easy to implement), which I'm still not sure of. I don't really need any of the other benefits they provide.
  6. I'm writing a Windows service, the continued operation of which is important. To deal with crashes, the OS can be configured to automatically restart it. What may also happen, however, is it just getting stuck somehow. I've already seen this happen when network calls go wrong; once OpenSSL got into a faulty state and blocked forever. Now I'm looking for the best way to terminate the process when it seems like it's no longer doing any work for too long. A few options I can think of: 1. Doing the work in a separate thread that is monitored from the main thread 2. Doing the work in a child process that is monitored by the parent 3. Doing the work in the parent process that is monitored by a child 4. Doing the work in a process that is scheduled to be killed by Windows First of all, I'm not sure if I need process isolation or not. Can one thread cause the whole process to hang, i.e. all threads, including those it has no interaction with? Process isolation might be ideal, but it also brings complications (e.g. logging to the same file) that I could do without. If 1 is not good enough, do I really need to go for 2 or 3, or could 4 work well enough? If a schedule timer-queue timer is fired to terminate the process when stuck, does that running in a Windows-owned thread make it any different (in terms of reliability) from 1? Would it still work when the process is completely stuck? Is there another, better way to let Windows handle the situation? Between 2 and 3, is there any meaningful difference?
  7. Thijs van Dien

    InterBase or Firebird?

    Proprietary databases are a no go IMHO, when there are plenty of excellent alternatives.
  8. Thijs van Dien

    pre-generic dictionary class

    I was surprised by @dummzeuch's benchmark results, so ran my own. In short, I created 44350 strings by taking 8870 English words and appending 1 to 5 to them, added half of them (index odd) to the data structure, to finally check for all of them if they were present. The experiment was repeated 100 times, and the listed results are the average total time for each action: TStringList - Add: 143.44 ms - TryGet: 123.09 ms TStringHash (Size = 256) - Add: 23.58 ms - TryGet: 62.56 ms TStringHash (Size = 512) - Add: 17.09 ms - TryGet: 40.54 ms TStringHash (Size = 1024) - Add: 13.47 ms - TryGet: 29.3 ms TStringHash (Size = 2048) - Add: 11.45 ms - TryGet: 21.68 ms TStringHash (Size = 4096) - Add: 10.2 ms - TryGet: 18.41 ms TStringHash (Size = 8192) - Add: 9.49 ms - TryGet: 16.28 ms TStringHash (Size = 16384) - Add: 9.17 ms - TryGet: 15.21 ms TStringHash (Size = 32768) - Add: 8.73 ms - TryGet: 14.24 ms TStringHash (Size = 65536) - Add: 8.68 ms - TryGet: 14.03 ms TDictionary - Add: 10.2 ms - TryGet: 16.09 ms TSynDictionary - Add: 9.02 ms - TryGet: 14.99 ms If you're really interested, I can send you the code, but I think these results make sense. As long as the number of buckets is somewhat appropriate, a TStringHash outperforms TDictionary even. Possibly the former has a more specialized hash function, or simply does less other work (e.g. no accounting for reallocation). Note that I did make it fair by checking for duplicates in TStringHash too. If you don't need that, it becomes even faster.
  9. Thijs van Dien

    pre-generic dictionary class

    TStringHash is a completely different class than THashedStringList and gives you exactly what you asked for: string to Integer (Pointer). I've been happily using it in D6 and it's still publicly available in D2010 (the latest version I have at hand). Sure it might not be the absolute optimal solution, but it will be a noticeable improvement over the status quo, is very understandable, and doesn't need any third party code.
  10. Thijs van Dien

    pre-generic dictionary class

    Did you consider IniFiles.TStringHash? It has a fixed number of buckets, but you could compose it and implement your own reallocation logic if desired. Also, you could inherit from it to use a better hash should the default not be good enough.
  11. Thijs van Dien

    JSON as a way to save information in Firebird

    I would suggest to at least not go the JSON route. If you don't want to go fully relational, and don't have too much nesting, you could use something like the Entity-Attribute-Value (EAV) pattern. When done correctly, that's still quite workable with a RDBMS like Firebird while already offering greater flexibility (with which also comes greater responsibility). It could strike a nice balance.
  12. Thijs van Dien

    Recommended Cryptographic Library

    If you can get away with its limited functionality (which is sort of the point), just use libsodium.
  13. Thijs van Dien

    Signing executables

    @Vincent Parrett Later versions of Inno Setup have several options for retrying, so it's not a problem for me. The only thing that still doesn't work to well is aborting the compilation when it's signing.
  14. Thijs van Dien

    Signing executables

    I have a certificate issued by Comodo and let Inno Setup take care of it. As also covered in the blog post linked above, if you obtain a timestamp from a trusted party (special server) when signing, the signature will remain valid. For me the most useful resource was this: https://www.zabkat.com/blog/code-signing-sha1-armageddon.htm.
  15. Thijs van Dien

    Blogged : Delphi Package Manager RFC

    A proper way to make design-time packages part of my project rather than of my IDE is just about the only thing that could get me to upgrade Delphi ever again. I'm sure it will be technically challenging, and that any implementation would be buggy for a long time (as with most even mildly complicated new features), but done well it would be a big step forward. Yes, packages would have to be made compatible with it, but the same was true for GetIt. As long as the old style "IDE packages" keep working too, I don't see the problem. It could be a chance to streamline how packages must be written and hopefully adding any paths would no longer be necessary for such "project packages". If it will still be possible for such packages to make hard to reverse changes to the IDE at runtime, some kind of sandboxing would be needed.