shared - i need it to be useful

[Manu]

On Sun, Oct 21, 2018 at 5:50 AM Stanislav Blinov via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Sunday, 21 October 2018 at 05:47:14 UTC, Manu wrote:
>
> >> And yet, if we're lucky, we get
> >> a consistent instacrash. If we're unlucky, we get memory
> >> corruption, or an unsolicited write to another currently open
> >> file, either of which can go unnoticed for some time.
>
> > Woah! Now this is way off-piste..
> > Why would get a crash? Why would get memory corruption? None of
> > those things make sense.
>
> Because the whole reason to have `shared` is to avoid the
> extraneous checks that you mentioned above,

No, it is to assure that you write correct not-broken code.

> and only write actual
> useful code (i.e. lock-write-unlock, or read-put-to-queue-repeat,
> or whatever), not busy-work (testing if the file is open on every
> call).

`shared` is no comment on performance. You have written a slow locking API.
If you care about perf, you would write a completely different API
that favours perf.
This not impossible, nor even particularly hard.

> If you have a `shared` reference, it better be to existing
> data.

I mean, if I dereference a pointer, it had better not be null!

> If it isn't, the program is invalid already: you've shared
> something that doesn't "exist" (good for marketing, not so good
> for multithreading).

I mean, if I dereference a pointer, it had better not be null!

> That's why having `shared` and un-`shared`
> references to the same data simultaneously is not safe: you can't
> guarantee in any way that the owning thread doesn't invalidate
> the data through it's non-`shared` reference while you're doing
> your threadsafe `shared` work; you can only "promise" that by
> convention (documentation).

The owning thread is not a special actor. Your reasoning is wonky here.
Lets say there is no owning instance, only a collection of shared
instances... any one of them can theoretically do an operation that
interferes with the others.
That's issues for general threading, and no design for `shared` can
(or should) interact with that problem. That's a problem for
architecture.

> > So, you call closeFile immediately and read/write start
> > returning null.
>
> And I have partially-read or partially-written data.

I expect you flushed before killing the file.

> Or Maybe I
> call closeFile(), main thread continues and opens another file,
> which gives the same file descriptor, `shared` references to
> FileHandle which the user forgot to wait on continue to work
> oblivious to the fact that it's a different file now.

It's wild to suggest that ANY design for `shared` should somehow deal
with the OS recycling a file handle...
And it's still not an un- at safe crash! It's just a program with a bug.

> It's a
> horrible, but still @safe, implementation of FileHandle, yes, but
> the caller (user) doesn't know that, and can't know that just
> from the interface. The only advice against that is "don't do
> that", but that's irrespective of your proposal.

No proposal can (or should) address these issues. You're concerned
with an issue that is sooooo far left-field at this stage.
Programming languages don't validate that you wrote a working bug-free program.

> > I'm going to assume that `shareWithThreads()` was implemented
> > by an
> > 'expert' who checked the function results for errors. It was
> > detected that the reads/write failed, and an error "failed to
> > read file" was emit, then the function returned promptly.
> > The uncertainty of what happens in this program is however
> > `shareWithThreads()` handles read/write emitting an error.
>
> But you can only find out about these errors in `waitForThreads`,
> the very call that the user "forgot" to make!

...what?

> [ ... snip ... ]

You have to concede defeat at this point.

Destroy my proposal with another legitimately faulty program.


> I understand that. So... it would seem that your proposal focuses
> more on @safe than on threadsafety?

I am trying to achieve @safe-ty _with respect to threadsafety_.

'threadsafety' with respect to "proper program operation" is a job for
programmers, and program architecture.
No language attribute can make your program right.