Brain Candy posted:

tbh, i kinda get why c-grogs get mad about kids these days

because people can make sprawling-business-useful thing but never learn about resource management and so that happens

Space Whale posted:

The only reason this threadshit got checked in was nobody was doing code reviews, or, the people at $JOB when it was fully startup mode honestly didn't understand this - none of them.

Which scares me.

pseudorandom posted:

That's the dictionary definition for "startup". Unless it's started by a group of software engineers, they always start with one confident guy who builds the whole company's software with no oversight.


Then a few people are hired on, and they deal with the spaghetti and meatballs cooked by the CTO (presumably his title).

Startups live or die by the stage after that in which one hero must essentially rewrite, or completely refactor, the product to make it maintainable.

Space Whale posted:

I'm also still just in awe that we have, in production, try/catch/gotos.

Bloody posted:

you sure youre not workin on flight software

Space Whale posted:

So how do you scale iis hosted poo poo, besides "lol IIS do my thing"?

To address your point: making less knowledgeable people useful is A Good Thing, for sure. The only reason this threadshit got checked in was nobody was doing code reviews, or, the people at $JOB when it was fully startup mode honestly didn't understand this - none of them.

Which scares me.

Shaggar posted:

wrt asp.net and controllers, it will basically run a thread per request and you don't need to do anything. Doing lots of work in a single thread will just increase the time the request takes.

As a general rule you should not spawn additional threads or background tasks that persist after the request you are handling. normal async calls are fine since they will complete during the normal course of the request. Launching a background worker to do something and then returning the response while the worker continues can lead to resource leaks or task failures if you don't handle edge conditions properly.

If you need to spawn a long running task from a request either run it entirely within the request and make the caller wait or submit the work item into a queue for processing by an external process.

wrt iis you can configure the number of cores available for the application process. pretty easy. read the docs

If you need to scale beyond a single IIS server you can use any of a billion load balancing solutions, but you need to take into account session management. If you are using sessions (you probably are) you either need to do a hack on your load balancers to stick clients to a single server or you need to have the session information available to all servers. consult the iis docs for this kind of thing.

Space Whale posted:

HoboMan posted:

HAHA, no wait, load balancing software?
you working on that system that went down a couple weeks ago and got my loving flight delayed by a couple hours?

Space Whale posted:

So how do you scale iis hosted poo poo, besides "lol IIS do my thing"?

To address your point: making less knowledgeable people useful is A Good Thing, for sure. The only reason this threadshit got checked in was nobody was doing code reviews, or, the people at $JOB when it was fully startup mode honestly didn't understand this - none of them.

Which scares me.

Shaggar posted:

wrt asp.net and controllers, it will basically run a thread per request and you don't need to do anything. Doing lots of work in a single thread will just increase the time the request takes.

Brain Candy posted:

also lmao that windows doesn't have a good epoll in TYOL 2019

Space Whale posted:

We make stuff that tells a pilot what settings to use, if the airplane is too heavy, if it's too hot for your altitude and weight, and engine out procedures, mostly. Also balance poo poo.

But yes Boeing can suck a fat one.

Plorkyeran posted:

these sound like things that could result in a crashed plane if you gently caress up enough

Plorkyeran posted:

these sound like things that could result in a crashed plane if you gently caress up enough

Space Whale posted:

Oh, very much so.

Space Whale posted:

So basically just loving rip the thread

Bloody posted:

synstructure, syn, quote, and proc_macro

i have these structs, and for all of them i keep writing this long mess of extremely boilerplate code, and i want to not do that, but i don't know what i'm doing, so it's going very poorly

quote:

0.3 Reference Parameter Threading

In addition to allowing multiple assignments to variables, the Bosque language also allows developers to thread parameters via ref argument passing. This alternative to multi-return values simplifies scenarios where a variable (often some sort of environment) is passed to a method which may use and update it. Allowing the update in the parameter eliminates the extra return value management that would otherwise be needed:

code:

function internString(ref env: Map<String, Int>, str: String): Int {
    if(env.has(str)) {              //use the ref parameter
        return env.get(str);
    }

    env = env.add(str, env.size()); //update the ref parameter
    return env.size();
}

Corla Plankun posted:

reading about the new language 'Bosque' and getting really upset about the inclusion of what they call "Reference Parameter Threading" and what I, a terrible programmer, call "loving with my values in the most deceptive way possible"

the overview doesnt seem to think that its weird that the initial premise that "All values in the Bosque language are immutable!" is immediately contradicted by


so maybe i'm just misunderstanding

Brain Candy posted:

also lmao that windows doesn't have a good epoll in TYOL 2019

gonadic io posted:

said mutable values are clearly marked. it depends if you can turn anything into a ref value later (which would be bad), or if you have to declare them as ref in the first place (in which case it's clear that they may get changed)

Asleep Style posted:

Forgive me if I'm stating the obvious re: unmanaged resources and the billion processes, but if I recall correctly in .NET Process implements IDisposable. If you had a process factory that wrapped these processes in a using block they should get GC'd when they go out of scope.

Powerful Two-Hander posted:

select em all 1989, I am ANSI man, 27193736 returned rows

Sapozhnik posted:

epoll isn't good either tbh

Luigi Thirty posted:

I ran an epoll and it came back 99% ron Paul

Shaggar posted:

its not so much about unmanaged resources used by the long running task (though you absolutely need to worry about them), but more about the task itself. You need to manage the total number of those long running tasks which is definitely doable, but its one more thing to remember to do properly in your code. Plus your long running tasks need to be incredibly durable as the application pool may terminate at any time and its not going to wait for your tasks to finish (unless you do some kind of hacky stuff).

The design of asp.net is centered around requests being totally independent of other requests. When you adhere to this design it makes things much easier to maintain. Its not designed to handle long running tasks, so there are no mechanisms to handle them built into the framework. This means you need to design them yourself which, while possible, is more code to maintain in a system not designed for what you're doing.

Aside from the code maintenance benefits of separating short and long running tasks, you make it easier to understand the performance profiles of your 2 systems. This makes it easier to scale the overall system since you've separated 2 totally different task profiles into totally different subsystems.

Luigi Thirty posted:

I ran an epoll and it came back 99% ron Paul

CRIP EATIN BREAD posted:

actually its very good. kqueue is better but whatever.

Luigi Thirty posted:

I ran an epoll and it came back 99% ron Paul

Shaggar posted:

its not so much about unmanaged resources used by the long running task (though you absolutely need to worry about them), but more about the task itself. You need to manage the total number of those long running tasks which is definitely doable, but its one more thing to remember to do properly in your code. Plus your long running tasks need to be incredibly durable as the application pool may terminate at any time and its not going to wait for your tasks to finish (unless you do some kind of hacky stuff).

The design of asp.net is centered around requests being totally independent of other requests. When you adhere to this design it makes things much easier to maintain. Its not designed to handle long running tasks, so there are no mechanisms to handle them built into the framework. This means you need to design them yourself which, while possible, is more code to maintain in a system not designed for what you're doing.

Aside from the code maintenance benefits of separating short and long running tasks, you make it easier to understand the performance profiles of your 2 systems. This makes it easier to scale the overall system since you've separated 2 totally different task profiles into totally different subsystems.

pseudorandom name posted:

https://idea.popcount.org/2017-02-20-epoll-is-fundamentally-broken-12/ https://idea.popcount.org/2017-03-20-epoll-is-fundamentally-broken-22/

also https://medium.com/@copyconstruct/the-method-to-epolls-madness-d9d2d6378642