Out of principle I'd say the paradigm should be adjusted so your code can handle callbacks as it's all networked anyways and latency is to be expected. Blocking like this on a single threaded platform is almost certainly bad news and doesn't reflect the normalcy of the era.

Out of principle I'd say the paradigm should be adjusted so your code can handle callbacks as it's all networked anyways and latency is to be expected. Blocking like this on a single threaded platform is almost certainly bad news and doesn't reflect the normalcy of the era.

When you look at socket coding in general the paradigm is to give the choice by having both threaded and non-threaded operations. Even Sourcemod does this with the SQL API. To force people to use threaded operations because you beleive there is no legitimacy for non-threaded operations is naive imo.

When you look at socket coding in general the paradigm is to give the choice by having both threaded and non-threaded operations. Even Sourcemod does this with the SQL API. To force people to use threaded operations because you beleive there is no legitimacy for non-threaded operations is naive imo.

Emphasis on the fact that it's a single threaded platform. Blocking would be fine if there was nothing else going on (e.g., utility scripts or simple applications), but there's expectations that a game server is able to respond in a predictable amount of time.

When you look at socket coding in general the paradigm is to give the choice by having both threaded and non-threaded operations.

No, it isn't.

Quote:

Originally Posted by Neuro Toxin

Even Sourcemod does this with the SQL API. To force people to use threaded operations because you beleive there is no legitimacy for non-threaded operations is naive imo.

Remember you have at the most 8ms to complete an operation before it's apparent to clients in-game. Using blocking operations like this to foreign servers is going to actively cause harm from an ancient mindset.