On Sun, Oct 21, 2018 at 5:50 AM Stanislav Blinov via Digitalmars-d <digitalmars-d@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-@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.
