3 ms·

call fork()

by yaur 5y ago

call fork()

justsomeuser 5y ago
The docs are quite specific where you can and cannot move connection pointers over threads. You should probably keep each connection owned by a single thread. This is a general “do not share memory” issue, you could fork any non-thread safe C code and see undefined behaviour. Any other issues?
- theamk 5y ago
  Mistakes happen. But only on sqlite, the "undefined behavior" means "all your data is gone". In postgres, you can crash or fail or get invalid results, but you are not going to lose all your data at once.
  - justsomeuser 5y ago
    But you cannot compare products based on the mistakes programmers make. We are all human. Any tool can be misused though. I think "do not share memory with multiple writers" is in the same category as "do not use a default user/pass, only allow access from the LAN". Both are programmer errors not related to the specific products they are implemented on top of.
    - theamk 5y ago
      Sure you can! One of the big selling points of Rust, for example, is that handing of programmers' mistakes -- if you look at original announcement [1], the first bullet means "when programmers make mistakes, they do not turn into security or crashing issues". That said, the "do not share" issue is not important for everyone. My Python code never calls fork, so that's not an issue at all. But I can easily imagine programs which do fork a lot. [1] https://lkml.org/lkml/2021/4/14/1023 https://lkml.org/lkml/2021/4/14/1023
      - justsomeuser 5y ago
        Ok you can compare products, but you still have to use/compare them without making any obvious mistakes. Using the Rust example, you could say “Rust is not safe because I can wrap my code in unsafe{} and that corrupts my data when I fork”. The OPs point is “when I run two threads that write to the same memory I get corrupt data”. The first point of call is not “well it’s Samsung memory, so Samsung make terrible memory modules, I shall run my incorrect programs on Sony henceforth”. It’s “why are you expecting your incorrect program to even work”.
        yaur 5y ago
        Actually fork does not create two threads it creates two processes which should "share memory" only in the "copy on write" sense. There is no undefined behavior implied here. When developers misunderstand the difference between thread and process boundaries (as in the case of the SQLite devs) things ca go to total shit real fast. If you replace "Samsung" with Unix and "Sony" with Microsoft your other statements are correct. That's the problem.

call fork()

by yaur 5y ago

call fork()

The docs are quite specific where you can and cannot move connection pointers over threads. You should probably keep each connection owned by a single thread. This is a general “do not share memory” issue, you could fork any non-thread safe C code and see undefined behaviour. Any other issues?

theamk 5y ago
Mistakes happen. But only on sqlite, the "undefined behavior" means "all your data is gone". In postgres, you can crash or fail or get invalid results, but you are not going to lose all your data at once.
- justsomeuser 5y ago
  But you cannot compare products based on the mistakes programmers make. We are all human. Any tool can be misused though. I think "do not share memory with multiple writers" is in the same category as "do not use a default user/pass, only allow access from the LAN". Both are programmer errors not related to the specific products they are implemented on top of.
  - theamk 5y ago
    Sure you can! One of the big selling points of Rust, for example, is that handing of programmers' mistakes -- if you look at original announcement [1], the first bullet means "when programmers make mistakes, they do not turn into security or crashing issues". That said, the "do not share" issue is not important for everyone. My Python code never calls fork, so that's not an issue at all. But I can easily imagine programs which do fork a lot. [1] https://lkml.org/lkml/2021/4/14/1023 https://lkml.org/lkml/2021/4/14/1023
    - justsomeuser 5y ago
      Ok you can compare products, but you still have to use/compare them without making any obvious mistakes. Using the Rust example, you could say “Rust is not safe because I can wrap my code in unsafe{} and that corrupts my data when I fork”. The OPs point is “when I run two threads that write to the same memory I get corrupt data”. The first point of call is not “well it’s Samsung memory, so Samsung make terrible memory modules, I shall run my incorrect programs on Sony henceforth”. It’s “why are you expecting your incorrect program to even work”.
      - yaur 5y ago
        Actually fork does not create two threads it creates two processes which should "share memory" only in the "copy on write" sense. There is no undefined behavior implied here. When developers misunderstand the difference between thread and process boundaries (as in the case of the SQLite devs) things ca go to total shit real fast. If you replace "Samsung" with Unix and "Sony" with Microsoft your other statements are correct. That's the problem.