I wanted to serve pages in my blog. The blog doesn’t actually exist yet (but works locally, need to find out how I can safely host it later…), but lets assume it becomes viral, and by viral i mean the entire internet has decided to use it. And they are all crazy picky about loading times…

Of course it depends if doing this kind of optimization work is your goal but... if you just want a blog and you want it to be fast (even with many visitors, but perhaps not the entire internet...), I would say make a static web server that just serves the blog pages directly from &'static strs and predefine all blog posts ahead of time. For example, you could write all your blog posts in HTML in separate files and include them into your code at compile time.

You'd need to recompile your code with new blog post entries in order to update your blog... but like how often are you gonna add to your blog? Recompiling and redeploying the blog server wouldn't be an issue I imagine. That's how I would do it if I wanted a fast and simple blog.

Also general software development wisdom says "don't code for the future" aka YAGNI - you aren't gonna need it. I mean, sorry, but chances are the whole internet will not be crazy about visiting your blog so probably don't worry about it that much 😅. But it is a good learning thing to consider I guess.

#[derive(Clone)]
pub struct Page<'a> {
   pub title: &'a str,
   pub endpoint: &'a str,
}

I'm a little confused about the use of the word "endpoint" here - that usually indicates an API endpoint to me but I would think it would be the post contents instead? But maybe I'm just too hung up on the word choice.

I wanted to create a HashMap that held all my pages, and when I updated a source file, the a thread would replace that page in the mapping.

To me, this sounds like you want to dynamically (i.e. at runtime, while the server is running) keep track of which blog entry files exist and keep a shared hashmap of all the blog files.

So there's multiple things with that:

1. You'd need to dynamically allocate the storage for the files on the heap as you load them in memory, so they'd need to be String or an Arc<str> if you only need to load it in once and not change it. Since you don't know at compile-time how big the blog posts are.
2. As you note, you'd need a way to share read-only references to the hashmap while also providing a way to add/remove entries to it at runtime. This requires some kind of lock-syncing like Mutex or RwLock, yes.

why can’t I have a AtomicPointer to my data that always exist?

Does it always exist though? The way you talk about it now sounds like it's loaded at runtime, so it may or may not exist. I think I'd need to see more concrete code to know.

and I’m actually calling unsafe code. I have heard it can produce unexpected error outside it’s block.

Yes, indeed. Safe code must never produce undefined behaviour, but safe code assumes that all unsafe blocks does the correct thing. For instance, safe code will always assume a &str contains UTF-8 encoded data but some unsafe code may have earlier changed the data inside of it to be some random data. That will break the safe code that makes the assumption! But it's not the safe's code fault.

Unsafe in general is a very sharp tool and you should be careful. In the best case, your program crashes. In worse cases, your program continues with garbage data and slowly corrupts more and more. In the even worse case, your program almost always works but rarely produces undefined behaviour that is extremely hard to track down. You could also accidentally introduce security vulnerabilities even if your code works correctly most of the time.

In general, I would advise you to avoid unsafe like the plague unless you really need it. A hypothetical optimization is certainly not such a case. If you really want to use unsafe, you definitely need to carefully peruse the Rustonomicon first.

In your specific case, the problem is (of course) with the unsafe block:

unsafe { self.data.load(Relaxed).read_unaligned() }.clone()

So what is this doing? Well self.data.load(Relaxed) returns a *mut Arc<T> but it is only using safe code so the problem must be with the read_unaligned call. This makes sense, obtaining a raw pointer is fine, it's only using it that may be unsafe.

If we check the docs for the read_unaligned function, it says:

Reads the value from self without moving it. This leaves the memory in self unchanged.

Here "self" is referring to the *mut Arc<T> pointer. So this says that it reads the Arc<T> directly from the memory pointed to by the pointer.

Why is this a problem? It's a problem because Arc<T> is a reference-counted pointer, but you've just made one without increasing the reference count! So the Arc believes there are n references but in fact there are n + 1 references! This is bad! Once the Arc is dropped, it will decrease the reference count by 1. If the reference count is 0, it will drop the underlying data (the T).

So let's say you get into this situation with 2 Arcs but actually the reference count is 1. The first one will drop and will try to free the memory since the reference count is now 0. The second one will drop at some later time and try to update the reference count but it's writing into memory that has been freed so it will probably get a segmentation fault. If it doesn't get the segfault, it will get a problem once it tries to free the memory since it's already been free. Double free is bad!

So yea that's why it probably works once (first arc gets dropped) but not twice (second arc gets a bad experience).