7 ms·

If you think of it from a developer's view, you'll come to conclusion that you can't create a program that doesn't need to cleanup things before termination. Un

by khrf 12y ago

If you think of it from a developer's view, you'll come to conclusion that you can't create a program that doesn't need to cleanup things before termination. Unless it's very useless program that doesn't process any incoming data. That's why there is SIGTERM in operating systems.

angersock 12y ago
You very much can--it depends on what you're doing. Supporting SIGTERM and certain other signals is just deciding how big a crater you want to make when the program goes down. That said, it's good practice to use things (write-ahead logging, idempotent operations, etc.) that at least try to mitigate the amount of debris.
- rdtsc 12y ago
  > That said, it's good practice to use things (write-ahead logging, idempotent operations, etc.) that at least try to mitigate the amount of debris. Yap that are some of the things I used. Append only mode for files. Code that handle roll-back to last consistent state that runs on every startup. External monitors and watchdog that know how to monitor and to extra cleanup is necessary.
lomnakkus 12y ago
That's nonsense. All ACID databases handle the requirement that a SIGKILL doesn't corrupt data. There may be a non-trivial recovery cost if you experience an unexpected shutdown, but that's about it for any application that's serious about data integrity. EDIT: In fact they handle a much stronger requirement that a power failure doesn't corrupt data, but the point stands.
- vinceguidry 12y ago
  ACID databases can do this because they have the powerful hand of math giving them superpowers. Most developers don't.
  - pjscott 12y ago
    Sqlite is a library that you can just link to. Use that for your state-handling, and you need not fear a thousand SIGKILLs. This is a very popular approach. Or, if you're on a server, you can use another database. Or use atomic file writes, if you have fancy needs. If you have really exotic needs then sure, do your own thing -- but most of the time, killability is easy and beneficial.
    - vinceguidry 12y ago
      If you do that, then you have to model program state not as objects, but as database rows. Have fun using ORM on all your projects, for everything.
  - lomnakkus 12y ago
    "powerful hand of math". What? I did a pretty simple proof of the safety of Write-ahead Logging as an undergraduate project -- given reasonable assumptions about disks (or implementation safeguards such as pervasive checksumming). Most developers have superpowers: It's called "existing research". I just wish they'd use them more.
rdtsc 12y ago
> If you think of it from a developer's view, you'll come to conclusion that you can't create a program that doesn't need to cleanup things before termination. Nope. I did create a lot of complicated programs that work that way. Tested, shiped and got paid for them nicely.

by khrf 12y ago

angersock 12y ago

You very much can--it depends on what you're doing. Supporting SIGTERM and certain other signals is just deciding how big a crater you want to make when the program goes down. That said, it's good practice to use things (write-ahead logging, idempotent operations, etc.) that at least try to mitigate the amount of debris.

rdtsc 12y ago
> That said, it's good practice to use things (write-ahead logging, idempotent operations, etc.) that at least try to mitigate the amount of debris. Yap that are some of the things I used. Append only mode for files. Code that handle roll-back to last consistent state that runs on every startup. External monitors and watchdog that know how to monitor and to extra cleanup is necessary.

lomnakkus 12y ago

That's nonsense. All ACID databases handle the requirement that a SIGKILL doesn't corrupt data. There may be a non-trivial recovery cost if you experience an unexpected shutdown, but that's about it for any application that's serious about data integrity. EDIT: In fact they handle a much stronger requirement that a power failure doesn't corrupt data, but the point stands.

vinceguidry 12y ago
ACID databases can do this because they have the powerful hand of math giving them superpowers. Most developers don't.
- pjscott 12y ago
  Sqlite is a library that you can just link to. Use that for your state-handling, and you need not fear a thousand SIGKILLs. This is a very popular approach. Or, if you're on a server, you can use another database. Or use atomic file writes, if you have fancy needs. If you have really exotic needs then sure, do your own thing -- but most of the time, killability is easy and beneficial.
  - vinceguidry 12y ago
    If you do that, then you have to model program state not as objects, but as database rows. Have fun using ORM on all your projects, for everything.
- lomnakkus 12y ago
  "powerful hand of math". What? I did a pretty simple proof of the safety of Write-ahead Logging as an undergraduate project -- given reasonable assumptions about disks (or implementation safeguards such as pervasive checksumming). Most developers have superpowers: It's called "existing research". I just wish they'd use them more.

rdtsc 12y ago

> If you think of it from a developer's view, you'll come to conclusion that you can't create a program that doesn't need to cleanup things before termination. Nope. I did create a lot of complicated programs that work that way. Tested, shiped and got paid for them nicely.