Thread overview
Is there some kind of Blocking Queue for D?
2 days ago
Bienlein
2 days ago
Bienlein
2 days ago
Andy Valencia
2 days ago
Ali Çehreli
17 hours ago
Bienlein
3 minutes ago
Ali Çehreli
2 days ago

Hello,

I'm looking for some kind of blocking queue for D, that is if the queue is empty the thread doing a take on the queue is blocked until an item has been added to the queue. Couldn't find anything in the standard library.

Thank you, Oliver

2 days ago
On Thursday, July 10, 2025 3:22:30 AM Mountain Daylight Time Bienlein via Digitalmars-d-learn wrote:
> Hello,
>
> I'm looking for some kind of blocking queue for D, that is if the queue is empty the thread doing a take on the queue is blocked until an item has been added to the queue. Couldn't find anything in the standard library.

std.concurrency's send / prioritySend and receive / receiveOnly / receiveTimeout can be used in such a fashion:

https://dlang.org/phobos/std_concurrency.html#.send https://dlang.org/phobos/std_concurrency.html#.prioritySend https://dlang.org/phobos/std_concurrency.html#.receive https://dlang.org/phobos/std_concurrency.html#.receiveOnly https://dlang.org/phobos/std_concurrency.html#.receiveTimeout

- Jonathan M Davis




2 days ago
Thanks, Jonathan. The send and receive functions might do the job for some specific purpose, but I would like to have some general blockinglist class like an abstract data type.

I'm following the D forum for quite a while, but have so far only written little code in D mostly in order to better understand some features in D. I might take it as a D programming exercise to create some blockinglist wrapper around slist where addition and removal from the list is overwritten to signal some semaphore so that a take on an empty list would result in the calling thread being blocked because the semaphore count has reached 0.

2 days ago
On Thursday, 10 July 2025 at 14:28:31 UTC, Bienlein wrote:
> Thanks, Jonathan. The send and receive functions might do the job for some specific purpose, but I would like to have some general blockinglist class like an abstract data type.

It sounds like you have in mind shared memory coding techniques.  If you haven't yet, I suggest you write a number of applications in this style before you settle on an API.  D's view of multi-threaded shared memory is much less casual than what you're accustomed to in, say, C.  You can indeed write all the usual types of shared memory algorithms, but if your experience is like mine, the presence of the type system (and the "shared" type modifier) will make it a much more demanding experience.

And thus, by default, you'll often find recommendations leading to messaging rather than shared memory.

$0.02,
Andy

2 days ago
On 7/10/25 7:28 AM, Bienlein wrote:

> some blockinglist wrapper around slist

I would try std.concurrency first because its message queue is a blocking queue anyway if you limit the size with setMaxMailboxSize(). I have some examples of std.concurrency here:

  https://ddili.org/ders/d.en/concurrency.html

Ali

17 hours ago
On Thursday, 10 July 2025 at 23:57:48 UTC, Ali Çehreli wrote:
> On 7/10/25 7:28 AM, Bienlein wrote:
>
> > some blockinglist wrapper around slist
>
> I would try std.concurrency first because its message queue is a blocking queue anyway if you limit the size with setMaxMailboxSize(). I have some examples of std.concurrency here:
>
>   https://ddili.org/ders/d.en/concurrency.html
>
> Ali

Just saw that inside https://github.com/dlang/phobos/blob/master/std/concurrency.d there is a class MessageBox which does just what I want. Unhappily class MessageBox is private and therefore cannot be reused. I never understood the point of private inner classes as they prevent reuse. If you are forced to design for reuse you are also forced to think about reusable design which makes the design better (and besides allows for reuse).
3 minutes ago
On 7/11/25 11:36 PM, Bienlein wrote:

> Unhappily class MessageBox is private and therefore cannot be reused.

Ah! :) That's one more data point against 'private', that little feature that helps with nothing. I don't know what language invented it but I wouldn't be surprised if it came to D from C++.

The only thing 'private' achieves is this: You don't want your users to be disappointed when they go out of their way to use features that they are advised not to use, and those features behave differently in the future. Really? That never happens. Well, if it indeed happened ever, the user went out of their way to be surprised, didn't they?

Meanwhile, engineers like you suffer because of 'private'. I pick engineering over 'private' any day.

Ali