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