https://issues.dlang.org/show_bug.cgi?id=14953

Sean Kelly <sean@invisibleduck.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sean@invisibleduck.org

--- Comment #1 from Sean Kelly <sean@invisibleduck.org> ---
I think this can be handled a few different ways.  The most straightforward would be to do:

    m_localBox.clear();
    m_localPty.clear();

Which would wipe everything.  It might be better (albeit slower) to let the user supply a filter though.  Basically:

    discard(int,int,int);

Removes all messages that would map to:

    receive((int, int, int) {});

And:

    discard(Variant);

Would effectively clear the mailbox.  Perhaps this second version could special case to the efficient:

    m_localBox.clear();
    m_localPty.clear();

mentioned above.

--

https://issues.dlang.org/show_bug.cgi?id=14953

--- Comment #2 from Sean Kelly <sean@invisibleduck.org> ---
That said, it seems like the underlying problem here may be dataflow-related. How do you know that all pending messages are really no longer relevant?  If messages are really backing up (ie. something is producing more than you can consume), maybe the dataflow is incorrect.  More consumers are needed, or maybe some sort of throttling mechanism.

My concern is that I'm not sure that messages should ever be just discarded in bulk.  I'd love to hear a good example where they should.  So while the API seems straightforward, I'm not entirely convinced that it should exist. Thoughts?

--

https://issues.dlang.org/show_bug.cgi?id=14953

--- Comment #3 from Chris <wendlec@tcd.ie> ---
I understand your concerns regarding data flow. However, it's up to the user (programmer) to determine whether or not the pending messages are relevant.

A use case: a text-to-speech synthesizer that has several sentences in the queue (e.g. reading out a document's content sentence by sentence or spelling out a word letter by letter). When the user presses a button to cancel the speech, the remaining items in the queue that haven't been spoken yet should be flushed immediately, which is the desired behavior, else the user would have pressed "pause".

I'm sure there are other use cases.

If the API is flexible enough to offer a mechanism for both an immediate and a selective (filtered) flush, as you suggested, I think we're on the safe side. We should definitely have a method with a filter too.

--

https://issues.dlang.org/show_bug.cgi?id=14953

--- Comment #4 from Chris <wendlec@tcd.ie> ---
Related to this is the possibility to get the size of the message box, e.g. you would only want to flush a message box, if its size is > 0. I haven't found a way to get the size of the message box, unless something has escaped me.

I could open a new ticket for this. Thoughts?

--

https://issues.dlang.org/show_bug.cgi?id=14953

Dmitry Olshansky <dmitry.olsh@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dmitry.olsh@gmail.com

--- Comment #5 from Dmitry Olshansky <dmitry.olsh@gmail.com> ---
> Related to this is the possibility to get the size of the message box, e.g. you would only want to flush a message box, if its size is > 0. I haven't found a way to get the size of the message box, unless something has escaped me.

In an async world with fire and forget message passing all of the above is marred with race conditions. You might check that size == 0 the next instant the message comes in.

I think the only legitimate use case would be dropUntil!(SomeMessageTypesHere) as it at least has a point of serialization - marker message in a stream of messages.

--

https://issues.dlang.org/show_bug.cgi?id=14953

--- Comment #6 from Chris <wendlec@tcd.ie> ---
You assume a scenario where the programmer has no control over the data flow and messages can come from anywhere in at random, which is not necessarily the case. If threads follow a message passing protocol there is naturally some sort of synchronization between the threads.

--

https://issues.dlang.org/show_bug.cgi?id=14953

--- Comment #7 from Sean Kelly <sean@invisibleduck.org> ---
I think there's already a bugzilla for getting the mailbox size.  It's definitely come up before, and would be a trivial change.  The way the MessageBox code works is it has a thread-local queue and then a shared queue. When a match isn't found in the thread-local queue the shared queue is moved to the local queue and the match continues on the new messages.  All of these operations (empty queue, get size, etc) would operate on the local queue only. Touching the shared queue in any way requires acquiring a mutex, which is generally not what you want for these operations.  In essence, messages in the shared queue are messages that "arrived" after your operation was executed.

--

https://issues.dlang.org/show_bug.cgi?id=14953

--- Comment #8 from Chris <wendlec@tcd.ie> ---
That's perfectly all right. It should be thread local, because it only concerns the thread in question. But the programmer should have control over any local thread. At the moment it's a bit like as if a thread was a higher being and had a life of its own and you're not meant to interfere with it. However, threads are part of a program's logic and programmers should be able to control them just as they control the main thread.

--

https://issues.dlang.org/show_bug.cgi?id=14953

--- Comment #9 from Sean Kelly <sean@invisibleduck.org> ---
In general I agree.  However, one key feature of std.concurrency is that it can use different Schedulers to achieve different performance requirements.  So general actor code should never simply assume it's being run in a dedicated kernel thread or whatever.  But as this is a systems language, if you explicitly specify the Scheduler at initialization time, then code written specifically for that application can exploit this knowledge and call the low-level core.thread routines as needed.  The assumption being that if you specify the Scheduler then you Know What You're Doing and accept any consequences for mistakes.

--

https://issues.dlang.org/show_bug.cgi?id=14953

--- Comment #10 from Chris <wendlec@tcd.ie> ---
I see. It still may be necessary to know the size of the message box and be able to flush it. The fact that messages stick around for the life span of the thread can lead to undesired behavior, especially when the thread is meant to be running in the background for the duration of the program. You may close a thread down, once you're no longer interested in the message box, and start a new one for the next input, but that seems rather wasteful and may block the main thread while it is waiting for the closing down protocol to finish. I can imagine that this may be an issue for computer games. If there is a good solution other than introducing a new method to flush the message box, I'd be happy, but so far I haven't found it.

--