On Mon, Oct 22, 2018 at 4:50 AM Stanislav Blinov via Digitalmars-d
<digitalmars-d@puremagic.com> wrote:
>
> 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?..)
I did correct that line (along with an apology) on my very next post;
it would probably be a member of Job... or any manner of other code.
That is the least interesting line in the program
> 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*.
You're right, it's mostly 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.
I mean, it's fair, but it's pretty bloody hypocritical coming from you!
I think it's fair to point out that your high-frequency, persistent,
and unwavering hostility from post #1 across all my recent threads (at
least, until I told you to GF) is the primary reason I'm frustrated
here.
You can own part responsibility for my emotion.
