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

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.

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

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

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).

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

On Saturday, July 12, 2025 5:55:39 PM Mountain Daylight Time Ali Çehreli via Digitalmars-d-learn wrote:
> 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.

Whereas I think that using private makes perfect sense when you want something to be an implementation detail. Exposing it means that you have to deal with someone using it, you have to design its API for public use, and you can't change it without breaking code. If anything, making something public when it doesn't need to be makes it harder to maintain and refactor that code. As far as public libraries go, any time that any symbol is public, someone is going to use it, and you're stuck with its design.

And when the code is open source, if someone wants to use it, they can always just copy it into their own code and do whatever they want with it without creating any additional burden for the maintainers of the library that the code was taken from.

The situation is somewhat different when you're dealing with proprietary code, because then you're not usually dealing with external users, and you can change things more freely. But when you make a symbol public in a library which is publicly available, you're essentially creating a contract with your users and limiting the changes that you can make to the those symbols. So, there's a real cost to making a symbol public, and I'm 100% in the camp that symbols should not be public if they don't need to be.

Obviously, there are cases where designing an API from pieces that are public can be valuable, but IMHO, the mere fact that something is used to build something that is part of a public API is not in and of itself enough to merit that building block being public. Public symbols need to be purposefully designed as public symbols, whereas private symbols are implementation details which can be changed as necessary so long as those changes don't break the functionality provided by the public symbols. So, from the standpoint of code maintenance, there can be real value in keeping symbols private.

- Jonathan M Davis

On Sunday, 13 July 2025 at 00:35:42 UTC, Jonathan M Davis wrote:
> 
> And when the code is open source, if someone wants to use it, they can always just copy it into their own code and do whatever they want with it

Not necessarily true, part of the issue with autodecoding is that string.front is a fairly spooky reference inside 5 layers deep of template hell.

If I want to unprivate a thing in sumtype, but another package returns a sumtype; my local copy of sumtype will be treated as a different one unless I changed my system level flags

Given the everything imports everything phoboes style, you probably have to full copy and then break the implicit linking to the system version for several in theory simple changes.