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.
