OSDev.org

Brendan wrote:it's just sometimes I feel like I'm defending rather than explaining

The best ideas are always worth defending.

It probably has more to do with the main benefits being for users rather than developers. For example, the asynchronous messaging makes things harder for developers, not easier, because it forces them to minimize thread blocking rather than providing them with the possibility of being lazy and using something like "fopen()" without thinking about it. Of course things like libraries don't help with this - sometimes it seems that as long as it works no-one cares how it works.

Hmmm... When I was talking about benefits for developers, I meant giving them the ability to leverage the hardware more efficiently. IMO, convenience is a separate issue, and libraries can help here. They can't take away the concept that something asynchronous is going on, but they can make it convenient to do things asynchronously (e.g. -- "futures" could easily use your non-blocking messaging under the hood).

Don't get me wrong here - there are a lot of very good programmers who actually would use something like thread pools and "futures" support, but there are also plenty of programmers who've never written anything that uses more than one single threaded process. For your profession, I'd expect that your colleagues would be the former rather than the latter, but I wouldn't consider your colleagues to be a good statistical sample.

Those programmers stuck in a single-threaded world will be in for a nasty shock now that everything is going multi-core. I hope they all read this eventually...

Colonel Kernel wrote:

Brendan wrote:it's just sometimes I feel like I'm defending rather than explaining

The best ideas are always worth defending.

As somebody put it nicely:

Don't worry about people stealing your ideas. If your ideas are any good, you are going to have to ram them down their throats.

Hmmm... When I was talking about benefits for developers, I meant giving them the ability to leverage the hardware more efficiently. IMO, convenience is a separate issue, and libraries can help here. They can't take away the concept that something asynchronous is going on, but they can make it convenient to do things asynchronously (e.g. -- "futures" could easily use your non-blocking messaging under the hood).

Nonblocking messaging, in which the action is not performed, is in my opinion really bad programming. It's used to make nonthreaded applications do two things at once, by trying both of them alternatingly until one succeeds. Async messaging, in which the action is always performed, but not at that time, is good. I'm not sure which of the two you intend (Brendan). Are you sure you intend nonblocking?

Hi,

Candy wrote:Nonblocking messaging, in which the action is not performed, is in my opinion really bad programming. It's used to make nonthreaded applications do two things at once, by trying both of them alternatingly until one succeeds. Async messaging, in which the action is always performed, but not at that time, is good. I'm not sure which of the two you intend (Brendan). Are you sure you intend nonblocking?

I actually mean asynchronous messaging - I just keep forgetting how to spell it. ::)


Cheers,

Brendan