all OS functions should be "nothrow @trusted @nogc"
Shachar Shemesh via Digitalmars-d
digitalmars-d at puremagic.com
Tue Jul 25 07:39:15 PDT 2017
On 25/07/17 17:24, Moritz Maxeiner wrote:
> On Tuesday, 25 July 2017 at 13:50:16 UTC, Shachar Shemesh wrote:
>> The title really does says it all.
>
> Since you explicitly state *all* OS functions:
> nothrow: Should be OK (only callbacks could violate this and they should
> be nothrow, anyway).
Technically, any system call that is a pthreads cancellation point may
throw a C++ exception.
If we go down that route, however, calling system calls from nothrow
becomes completely impossible, which is another way of saying that
decorating just about anything with nothrow becomes impossible.
> @trusted: This can only be done for those functions that don't take
> arguments open to memory corruption. Take a look at POSIX read, it can
> never be trusted (same as any C function taking pointer+length of
> pointed to).
> @nogc: This can only be done for those functions that are statically
> known to never call a D callback that's not also @nogc. Take a look at
> pthread_create vor pthread_join, they can never be @nogc, because that
> would mean threads may never allocate with the GC.
The decoration's situation with callbacks is pretty horrible throughout
D. I'm not sure this is the most compelling argument, however. The
function passed to pthread_create does not, logically, run in the
pthread_create function. As such, I don't think this logic holds.
As for pthread_join, I have no idea what you meant by it. Please
elaborate why you think it is a problem.
>
> ---
> auto result = () @trusted { return systemFunction(...) }();
> ---
Care to explain how to adapt that neat trick for "nothrow" and "@nogc"?
Shachar
More information about the Digitalmars-d
mailing list