On Sunday, 21 October 2018 at 19:22:45 UTC, Manu wrote:
On Sun, Oct 21, 2018 at 5:50 AM Stanislav Blinov via
Digitalmars-d <digitalmars-d@puremagic.com> wrote:
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.
You can do that without `shared`.
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.
You're conflating your assumptions about the code with the topic
of this discussion. I can write a million examples and you'll
still find a million reasons to talk about how they're
incorrectly implemented, instead of focusing on merits or
disadvantages of your proposal with the code given as is.
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!
Why would you share a null pointer?
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.
Why have it then at all? If it's not a "special" actor, just make
all shared data `shared`. But your proposal specifically targets
the conversion, suggesting you *do* need a special actor.
And I have partially-read or partially-written data.
I expect you flushed before killing the file.
So? The threads still weren't done yet.
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...
I'm not suggesting that at all, you've completely misrepresenting
what I'm saying by splitting a quote.
And it's still not an un-@safe crash! It's just a program with
a bug.
Ok, if you say that sticking @safe on code that can partially
piece together data from unrelated sources is fine, then sure.
> I'm going to assume that `shareWithThreads()` was implemented
> by an 'expert' who checked the function results for errors...
But you can only find out about these errors in
`waitForThreads`, the very call that the user "forgot" to make!
...what?
Please suggest another way of handling errors reported by other
threads. More `shared` state?
[ ... snip ... ]
You have to concede defeat at this point.
I agree. No matter how hard I try or how many times I ask you to
demonstrate, I still fail to see the value in assuming @safe
implicitly conversion of mutable data to shared. Instead of
defending your proposal, you chose to attack the opposition.
You've defeated me, flawless victory.
Destroy my proposal with another legitimately faulty program.
Is there a point? I post code, you: "nah, that's wrong". Steven
posts code, you: "nah, that's wrong". Timon posts code, you:
"nah, that's wrong". Walter posts code, you: "nah, that's
wrong"... What's right then?
