shared - i need it to be useful

[Stanislav Blinov]

On Monday, 22 October 2018 at 00:22:19 UTC, Manu wrote:

> No no, they're repeated, not scattered, because I seem to have 
> to keep repeating it over and over, because nobody is reading 
> the text, or perhaps imaging there is a lot more text than 
> there is.
> ...
> You mean like every post in opposition which disregards the 
> rules and baselessly asserts it's a terrible idea? :/
> ...
> I responded to your faulty program directly with the correct 
> program, and you haven't acknowledged it. Did you see it?

Right back at you.

Quote:

I think this is a typical sort of construction:

struct ThreadsafeQueue(T)
{
   void QueueItem(T*) shared;
   T* UnqueueItem() shared;
}

struct SpecialWorkList
{
   struct Job { ... }

   void MakeJob(int x, float y, string z) shared  // <- any thread 
may
produce a job
   {
     Job* job = new Job; // <- this is thread-local
     PopulateJob(job, x, y, z); // <- preparation of a job might be
complex, and worthy of the SpecialWorkList implementation

     jobList.QueueItem(job);  // <- QueueItem encapsulates
thread-safety, no need for blunt casts
   }

   void Flush() // <- not shared, thread-local consumer
   {
     Job* job;
     while (job = jobList.UnqueueItem()) // <- it's obviously safe 
for
a thread-local to call UnqueueItem even though the implementation 
is
threadsafe
     {
       // thread-local dispatch of work...
       // perhaps rendering, perhaps deferred destruction, perhaps
deferred resource creation... whatever!
     }
   }

   void GetSpecialSystemState() // <- this has NOTHING to do with 
the
threadsafe part of SpecialWorkList
   {
     return os.functionThatChecksSystemState();
   }

   // there may be any number of utility functions that don't 
interact
with jobList.

private:
   void PopulateJob(ref Job job, ...)
   {
     // expensive function; not thread-safe, and doesn't have any
interaction with threading.
   }

   ThreadsafeQueue!Job jobList;
}


This isn't an amazing example, but it's typical of a thing that's
mostly thread-local, and only a small controlled part of it's
functionality is thread-safe.
The thread-local method Flush() also deals with thread-safety
internally... because it flushes a thread-safe queue.

All thread-safety concerns are composed by a utility object, so 
there's no need for locks, magic, or casts here.

EndQuote;

The above:
1) Will not compile, not currently, not under your proposal 
(presumably you forgot in frustration to cast before calling 
PopulateJob?..)
2) Does not in any way demonstrate a practical @safe application 
of an implicit conversion. As I wrote in the original response to 
that code, with that particular code it seems more like you just 
need forwarding methods that call `shared` methods under the hood 
(i.e. MakeJob), and it'd be "nice" if you didn't have to write 
those and could just call `shared` MakeJob on an un-`shared` 
reference directly. But these are all assumptions without seeing 
the actual usage.

Please just stop acting like everyone here is opposing *you*. All 
you're doing is dismissing everyone with a "nuh-huh, you no 
understand, you bad". If it was just me, fine, it would mean I'm 
dumb and not worthy of this discussion. But this isn't the case, 
which means *you are not getting your point across*. And yet 
instead of trying to fix that, you're getting all snarky.