^^^this++

This is why I prefer C++.

*evil grin*

It's people like you what cause unrest.

Oh, it's especially fun to read these in the text client in reverse order.

""const considered harmful" considered harmful" considered harmful. (Don't make me bring Godwin in here.)

STFU and code.

Did that... created an executable that waits on your Windows domain controller to change its network settings before changing the workstation network settings (and renaming the hostname), because things go wrong if you don't do this sort of thing in the right order when you're 'randomizing' your network settings.

This job has me do some pretty strange things.

*grumble* Fucking multithreaded programming. Easier said than done...

Everyone says, "Why? It's easy!"

No. It isn't.

It is always a deception waiting to bite you in the ass someday while your customer breaths down your neck for a solution.

I try very hard to avoid multithreaded programming, or to recast the programming in asynchronous terms instead, so while the logic might feel dysjunct, at least most of the problems associated with true multithreading are mitigated.

That wasn't an option here, we're required to do some resource pooling stuff that isn't available off the shelf.

I get it... sometimes, you're forced into it. And it's never easy.

Heh. I remember our old friend Mr.T used to say that about a lot of bad design decisions. "I got railroaded into it!"

The thing is, if your code is built for event-driven asynchronous architecture, it's already **mostly** multi-threading ready. The only thing you need to worry about then is shared resource locking, which can be made easier by wrapping shared resources in a server process (in the Erlang sense of the term "process", not Unix-style process!). The complexities that everyone always complains about invariably involves POSIX-style thinking (which both Windows and POSIX-based environments use), which eschews the rigor of message passing for locking things willy-nilly.

Agreed.

Much easier to think about things in terms of asynchronous message passing than locking resources.

The locking resources approach is heinous, and mostly what I'm talking about when I say that multi-tasking is hard.

In C++, the asio library makes handling this stuff much, much easier, as it provides a very nice environment for what you've described.

I am. Computers are state machines. Objects (in the object-oriented programming sense) are state machines. Functional programming is, when you separate state from the combinatorial computation that FP is famous for, all about state machines. Monads (in Haskell, O'Caml, et. al.) are all about managing how state machines are built. Programmers invariably get into problems when they start thinking in ways that, at its core, doesn't have any relationship to states. What do all these different methods have in common? They're different notations and tools to help programmers manage state transitions.

2018-04-06 14:44 from kc5tja @uncnsrd
The thing is, if your code is built for event-driven asynchronous
architecture, it's already **mostly** multi-threading ready. The only

thing you need to worry about then is shared resource locking, which
can be made easier by wrapping shared resources in a server process (in

the Erlang sense of the term "process", not Unix-style process!). The

I feel like that just moves the problem somewhere else. Dealing with shared state always has complexities. For example, one of the problems I was dealing with was not so much locking-related, as it was a mistaken idea that we could delete something from the shared state, a little too early...

Thanks IG, I wouldn't want to quote myself ;-p

Even worse, I discovered that my "classic posts archive" has been lost and I had to go to the WayBack Machine to get it. Unfortunately that also means I've permanently lost anything added to the archive since 2009 or so. :(

so yeah, I'm not really a fan of event-driven unless the application naturally fits it (like answering UI input events or responding to HTTP queries). I know some people like to turn every program into one big event loop, and although I respect their mad skillz, I find it makes the program unreadable.