In multi-threaded environments, the current code won't behave properly. Multiple threads can created the same ID.

From the rand(3) manpage:

The function rand() is not reentrant, since it uses hidden state that is modified on each call. This might just be the seed value to be used by the next call, or it might be something more elaborate. In order to get reproducible behavior in a threaded application, this state must be made explicit; this can be done using the reentrant function rand_r().

The difficulty in deciding what to do is that I would prefer to avoid Linux-specific APIs. So perhaps a stopgap would be a semaphore/spinlock. In the worst case, this would stall other threads for ~20 nanoseconds.

A few more changes to the C APIs, hopefully making them safer and (a bit) more natural to use. Commit b7bfb81239b8 has the bulk of them, and a more in depth explanation.

Hi,

I saw your tweet asking for opinions on how ergonomic the C/C++ API is, and while I'm not well suited to answer that, I wanted to see how you implemented this library. While taking a look at the code, I think I may have accidentally spotted a couple of problems.¹

The first is that ulid_new() appears to return a pointer to the stack: it creates a new Ulid on the stack, transmutes it to a UlidArray, and returns a pointer to it. There are no allocations, so isn't that a pointer to the stack and, more importantly, a pointer that becomes invalid as soon as that function returns? Miri seems to agree.

Another issue, is that in ulid_new_string() the returned pointer is derived from a temporary String (created with Ulid::new().to_string()), which is immediately dropped, making the pointer invalid. Miri also seems to agree.

That string is also allocated with Rust's Global allocator, so it's probably not sound to free it with any other allocator.

As a minor final observation, the function transmutes a const pointer into a mutable one. This is (probably) fine in that instance, as at that point we own the value anyway, but wouldn't as_mut_ptr() be a bit more direct?

P.S. The Miri examples used a simplified implementation to avoid calling functions from libc, which Miri doesn't yet support.

¹ I'm pretty new to Rust, and even more so to unsafe Rust. So I'm sorry if I'm missing something obvious...

This is a follow up to our email conversation.

As in this design both ulid_new_string() and ulid_write_new() would be identical, the latter is dropped.

Due to the increased number of tests, a problem with rand() not being reentrant became a lot more apparent. The tests can be made to work reliably with --test-threads 1, but a proper solution is still needed, as that is a bug that affects normal use of the public APIs.

Most of the tests can also be executed in Miri with:

MIRIFLAGS="-Zmiri-disable-isolation" cargo +nightly miri test

(-Zmiri-disable-isolation is required for SystemTime::new() ).

I have been working to improve the Rust API and also fix #8 by avoiding rand().

use ulid::{UlidGenerator};

fn main() {
    let mut ulid_gen = UlidGenerator::new();
    for _ in 0..10 {
        println!("{}", ulid_gen.ulid());
    }
}

You still have the ability to seed things yourself:

use ulid::{UlidGenerator};

fn main() {
    let mut ulid_gen = UlidGenerator::from_seed(12345);
    for _ in 0..10 {
        println!("{}", ulid_gen.ulid());
    }
}

New benchmarks are promising. My laptop can now produce a ULID in ~28 nanoseconds.

TODO

• [x] use thread_rng API provided by the xorshift crate
• [x] update documentation

We've recently introduced libc::ERANGE with the chance in C APIs. One thing to decide is the supported platforms for ulid-lite - because libc is less standard than I would have hoped.