5 ms·

So both versions of log crate manage their own internal states within the same process? Would this lead to surprising results?

dwattttt 2y ago
Their internal states in Rust are also namespaced, so two incompatible crates in the same process won't observe each others symbols. If they access external resources that are not namespaced though, that could be a problem.
- tick_tock_tick 2y ago
  Such as stdout or stderr that a log crate would be using?
  - dwattttt 2y ago
    That's not a very clear example. You don't need to be using multiple versions of the same dependency to contend on access to stderr/out, just having a println in your code along with logging code will have the same effect. I haven't ever observed a problem of concurrent access to stdout/err though, I expect because the methods for accessing stdout/err lock them for the duration of their printing. If you Google for "Rust print console slow", you'll probably find advice to explicitly lock it, to avoid individual printlns from each acquiring the lock.
- amelius 2y ago
  How would that work for malloc? How can you have two different functions manage the same heap?
  - anonymoushn 2y ago
    "The same heap" isn't a coherent concept here. Your malloc-implementing memory allocator has some global state, and that state has some pointers to some addresses it got from mmap and some metadata about how long those spans of memory are, which parts are unused, and how long the values it has returned from malloc previously are. If you managed to use two of these, they would each contain data referring to different non-overlapping sets of memory mappings. If you accidentally used a pointer from one with the other, you would go instantly to C UB land: The free() function frees the memory space pointed to by ptr, which must have been returned by a previous call to malloc(), calloc() or realloc(). Otherwise, or if free(ptr) has already been called before, undefined behavior occurs. If ptr is NULL, no operation is performed.
    - amelius 2y ago
      But malloc calls sbrk(), right?
      - dwattttt 2y ago
        I can't speak to multiple users of sbrk, I assume that would fail. That's a property of sbrk though, not of malloc (or memory allocation in general); on Windows, you can have as many implementors of malloc as you want, so long as malloc/free calls happen to the same implementor. Each malloc implementor just asks for anonymous backing pages for their own heaps (via VirtualAlloc/mmap).
      - unusual-name 2y ago
        It depends on the implementation. For example, jemalloc can use sbrk(), sbrk() and mmap() or just mmap(), depending on what your os supports.

dwattttt 2y ago

Their internal states in Rust are also namespaced, so two incompatible crates in the same process won't observe each others symbols. If they access external resources that are not namespaced though, that could be a problem.

tick_tock_tick 2y ago
Such as stdout or stderr that a log crate would be using?
- dwattttt 2y ago
  That's not a very clear example. You don't need to be using multiple versions of the same dependency to contend on access to stderr/out, just having a println in your code along with logging code will have the same effect. I haven't ever observed a problem of concurrent access to stdout/err though, I expect because the methods for accessing stdout/err lock them for the duration of their printing. If you Google for "Rust print console slow", you'll probably find advice to explicitly lock it, to avoid individual printlns from each acquiring the lock.
amelius 2y ago
How would that work for malloc? How can you have two different functions manage the same heap?
- anonymoushn 2y ago
  "The same heap" isn't a coherent concept here. Your malloc-implementing memory allocator has some global state, and that state has some pointers to some addresses it got from mmap and some metadata about how long those spans of memory are, which parts are unused, and how long the values it has returned from malloc previously are. If you managed to use two of these, they would each contain data referring to different non-overlapping sets of memory mappings. If you accidentally used a pointer from one with the other, you would go instantly to C UB land: The free() function frees the memory space pointed to by ptr, which must have been returned by a previous call to malloc(), calloc() or realloc(). Otherwise, or if free(ptr) has already been called before, undefined behavior occurs. If ptr is NULL, no operation is performed.
  - amelius 2y ago
    But malloc calls sbrk(), right?
    - dwattttt 2y ago
      I can't speak to multiple users of sbrk, I assume that would fail. That's a property of sbrk though, not of malloc (or memory allocation in general); on Windows, you can have as many implementors of malloc as you want, so long as malloc/free calls happen to the same implementor. Each malloc implementor just asks for anonymous backing pages for their own heaps (via VirtualAlloc/mmap).
    - unusual-name 2y ago
      It depends on the implementation. For example, jemalloc can use sbrk(), sbrk() and mmap() or just mmap(), depending on what your os supports.