Add phtread_key and readdir

[carbotaniuman]

This also fixes a bug in pthread_mutex_init, wherein a null pointer could've been dereferenced.

[carbotaniuman]

This does not yet handle destructors in pthread_key, as I'm not sure from where I should be registering the destructor.

[sunfishcode]

Interesting. The presence of undefined references to readdir on GLIBC indicates a code which has not been compiled with -D_FILE_OFFSET_BITS=64 or equivalent. In this case, it looks like the code in question is libgit2, so I've now filed rust-lang/git2-rs#862 to fix this. With that PR, libgit2 will use readdir64 instead of readdir, on GLIBC.

I wonder if it makes sense for mustang to leave readdir undefined, when target_env = "gnu", to help catch programs that haven't enabled _FILE_OFFSET_BITS=64/_TIME_BITS=64 yet.

[sunfishcode]

This does not yet handle destructors in pthread_key, as I'm not sure from where I should be registering the destructor.

We can register a function in pthread_setspecific with origin::at_thread_exit, on each thread the first time pthread_setspecific is called on that thread, using something like a #[thread_local] static Cell<bool>.

[sunfishcode]

Do you know if POSIX specifies this ordering?

Also, I realize this is being picky, but could you move this mention about pthread_cleanup functions to the pthread_cleanup_push/_pop function stubs themselves? Technically, we don't need to worry about that ordering until we implement those, and we might not do that for quite a while :-).

[carbotaniuman]

The first two are specified by POSIX:

Any clean-up handlers established by pthread_cleanup_push(3) that
have not yet been popped, are popped (in the reverse of the order
in which they were pushed) and executed. If the thread has any
thread-specific data, then, after the clean-up handlers have been
executed, the corresponding destructor functions are called, in
an unspecified order.

And the last two are specced by the C++ standard:

Destructors for initialized objects with thread storage duration within a given thread are called as a result of returning from the initial function of that thread and as a result of that thread calling std::exit. The completions of the destructors for all initialized objects with thread storage duration within that thread are sequenced before the initiation of the destructors of any object with static storage duration.

[sunfishcode]

Looking at this, I noticed that origin wasn't calling the TLS dtors on exit. I've now filed #133 for that.

Other than that, and other than ptthread_cleanup_push, I think we're ok.

[carbotaniuman]

other than ptthread_cleanup_push

I'm not quite sure what you're referring to here.

[sunfishcode]

I mean that we haven't implemented the ordering for destructors registered with pthread_cleanup_push yet, but that's ok for now because we haven't implemented pthread_cleanup_push yet.

[sunfishcode]

Thanks! I may still think about putting readdir under a cargo feature, to help people find codebases that haven't added -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64, which glibc needs, but we can figure that out later.