|
Soricidus posted:fibers this is like my least favorite thing about leaving the safe single-threaded confines of js async/await on a single-threaded event loop meant it was extremely easy to reason about concurrency because you knew, if you were in a sync function accessing some poo poo, that within that function it was absolutely impossible for it to change out from under you. the await breakpoints then told you "on the other side of this, something might have changed." it was nice! sure you had "colored functions" or whatever that stupid blog post is about, but in practice js has been async by default for i/o for years, it's other languages who are having trouble catching up (see: kotlin coroutines are kinda pointless because none of the jvm db libraries and only a handful of http servers/clients support them) now everyone suddenly wants this green thread stuff which i thought were thoroughly argued against here in a compelling way. when you have threads (green or non-green), you suddenly find yourself having to do poo poo like create awkward-to-use queues to prevent unwanted concurrency, and i hate this! threads are totally fine for cpu-intensive poo poo, but in your normal i/o-bound web context just give me one drat thread and an event loop with async/await or yield or whatever i don't really know where .NET async/await lands with all this? i assume given it's a non-plang you have all sorts of threading options, but i'm unclear if, for example, asp.net gets a (pooled) thread per request or if it single-threads everything synchronous i still haven't managed to figure out erlang, i dunno, maybe it'd make me see the light on this poo poo, but i'm skeptical. i assume they have like... patterns for abstracting over state so you never actually want shared state and thus it doesn't matter, or something
|
#
?
May 20, 2020 03:15
|
|
|
|
| # ? Apr 24, 2024 09:39 |
|
|
redleader posted:now all the jvm has to reinvent is supervisor trees and its convergence towards erlang will be complete erlang PLUS seconds-long STW GCs 
|
|
#
?
May 20, 2020 03:16
|
|
|
Erlang is very very deep in "don't communicate by sharing state, share state by communicating" territory. e: also all GC is very local
|
|
#
?
May 20, 2020 03:16
|
|
|
abraham linksys posted:this is like my least favorite thing about leaving the safe single-threaded confines of js seriously, just create 3000 threads and do thread-per-request, it’s not 1999 anymore. your app can’t handle 3000 concurrent anyway
|
|
#
?
May 20, 2020 03:18
|
|
|
abraham linksys posted:this is like my least favorite thing about leaving the safe single-threaded confines of js Just hold the state in its own thread. Then communicate between threads by dropping messages in thread safe queues. Easy.
|
|
#
?
May 20, 2020 03:19
|
|
|
node devs are so stockholmed they convinced the rest of the world that being able to use multiple cores is bad, actually. it’s very frustrating
|
|
#
?
May 20, 2020 03:21
|
|
|
leper khan posted:Just hold the state in its own thread. Then communicate between threads by dropping messages in thread safe queues. Easy. yeah i should probably be better at figuring out how to structure things like this i built a lil websocket chat server in kotlin and just threw a bunch of ConcurrentHashMaps at it and hoped for the best, i dunno. like, i use them to store "which rooms exist, and which users are in that room," which has to be saved somewhere. i dunno how you make something like that into thread-local state in javascript, i would be able to hold state like that in a singleton or whatever and never have to worry about it being concurrently accessed
|
|
#
?
May 20, 2020 03:24
|
|
|
Nomnom Cookie posted:node devs are so stockholmed they convinced the rest of the world that being able to use multiple cores is bad, actually. it’s very frustrating i dont know if it's relevant to the current discussion but this is very true, one of the dudes who worked on spotify spent ages soapboxing about how node.js was way more efficient than every other language, because you didnt have to worry about anything
|
|
#
?
May 20, 2020 03:33
|
|
|
blindly throwing threads around is basically the same as using goto for flow control. maybe worse
|
|
#
?
May 20, 2020 03:43
|
|
|
Bloody posted:blindly throwing threads around is basically the same as using goto for flow control. maybe worse it's rude to be talking about my posting like that
|
|
#
?
May 20, 2020 03:52
|
|
|
abraham linksys posted:this is like my least favorite thing about leaving the safe single-threaded confines of js so wrt ASP.net specifically, afaik its all single threaded per request with threads taken from the pool. Long running tasks and spawning additional threads from within a request thread are definitely possible, but are strongly discouraged because the application might get nuked at any time and your task/thread will lose all its state. java servlets work the same way afaik When writing asp.net you treat the code as if each request is totally independent of any other request (because it mostly is) and you dont really need to worry about them interacting beyond normal things like dont leak resources or dont create long running tasks.
|
|
#
?
May 20, 2020 04:15
|
|
|
Beamed posted:i dont know if it's relevant to the current discussion but this is very true, one of the dudes who worked on spotify spent ages soapboxing about how node.js was way more efficient than every other language, because you didnt have to worry about anything check out the top post of this page
|
|
#
?
May 20, 2020 04:40
|
|
|
Shaggar posted:so wrt ASP.net specifically, afaik its all single threaded per request with threads taken from the pool. Long running tasks and spawning additional threads from within a request thread are definitely possible, but are strongly discouraged because the application might get nuked at any time and your task/thread will lose all its state. java servlets work the same way afaik the obvious objection here being what about shared state? because thats what its about, doing some terrible poo poo with shared mutable state. ofc you know, but for the benefit of anyone who's not aware, big boy languages provide facilities to access databases, and that is where the shared mutable state goes. not in a blob squatting inside your process
|
|
#
?
May 20, 2020 04:43
|
|
|
depends on how the state is partitioned. If its chat data in a test app having it live in memory on your server is totally fine cause u aren't hosting multiple instances and you dont care if the data is lost when the process restarts. I did a chat app to try out websockets in signalr forever ago and I did litterrally the exact same thing, rpetty much just using a ConcurrentQueue for a chat buffer and ConcurrentDictionary for user state. It was one chat room and it all disappeared if the thing recycled, but it worked fine. Authentication was done w/ twitter so I didn't really need to worry about user account persistence. if I was gonna persist it across multiple instances i'd use some kind of db. but the bigger point is that the storage really shouldn't matter to the actual application code because you can always swap it to something else later if things are designed right. the application code (controller/hub) should just be getting some interface injected into it and then ur code is agnostic to the implementation. Your application code should not be worrying about resource contention because it should be handled in the storage implementation. idk how things work in node or w/e.
|
|
#
?
May 20, 2020 05:16
|
|
|
thats true. i forgot about abstraction, current job is python and its damaged me
|
|
#
?
May 20, 2020 05:32
|
|
|
asp.net is basically perfect
|
|
#
?
May 20, 2020 05:41
|
|
|
Bloody posted:asp.net core is basically perfect
|
|
#
?
May 20, 2020 05:44
|
|
|
Bloody posted:asp.net is basically perfect shame about the whole microsoft thing but yeah
|
|
#
?
May 20, 2020 05:49
|
|
|
Bloody posted:asp.net is basically perfect it's ok i guess
|
|
#
?
May 20, 2020 08:02
|
|
|
the js concurrency model is unironically the best thing in the language. if js had been created with a more traditional concurrency model (all threads all the time, molest shared and ui state as you will) then i'd probably have taken a long walk off a short pier by now
|
|
#
?
May 20, 2020 08:05
|
|
|
redleader posted:the js concurrency model is unironically the best thing in the language. if js had been created with a more traditional concurrency model (all threads all the time, molest shared and ui state as you will) then i'd probably have taken a long walk off a short pier by now y'know, i suppose this is a big difference, the model makes way more sense in a client side environment where you're mutating ui state than in a backend where your mutable state is likely going to be in some kind of database this is also true of anything with a "ui thread" i guess; don't most ios apps just use a single thread by default except for background services (i know i've seen a lot of articles like "how to move your slow poo poo off the ui thread" which makes me think it's all there by default atl east)
|
|
#
?
May 20, 2020 08:14
|
|
|
Yeah, most ui frameworks involve a single thread responsible for both changing the state of ui components and handing input messages on those components from the os. This is very convenient if you're writing ui components, because it means those components are essentially always single-threaded. Most client-app-developer's exposure to threads is "I want to do something blocking and/or cpu intensive, without having my ui lock up because the ui thread isn't doing those things any more".
|
|
#
?
May 20, 2020 08:21
|
|
|
Shaggar posted:so wrt ASP.net specifically, afaik its all single threaded per request with threads taken from the pool. Long running tasks and spawning additional threads from within a request thread are definitely possible, but are strongly discouraged because the application might get nuked at any time and your task/thread will lose all its state. java servlets work the same way afaik if you do need to spin up a thread in your web request you can use QueueBackgroundWorkItem which creates a thread that the application will wait for when recycling instead of nuking it like a normal thread
|
|
#
?
May 20, 2020 08:31
|
|
|
redleader posted:bbbut how can you ~scale~ without async hahaha threadripper go brrrr
|
|
#
?
May 20, 2020 08:43
|
|
|
We're having a bit of an async night mare just now. We have a system where users can save records and doing that might start a process that causes n other records to be saved. Now previously this has always been synchronous, you press save and everything gets save, easy. Now because our customers are idiots what they love to do is create processes with hundreds of stages and decision points in them. This was making things slow so we had to fix it. Now all this record saving was written in command pattern so it's actually really easy to just queue them and do it asynchronously, as long as you validate the process before you queue it then it can't really fail, so all good. This is where we made out first mistake, we added a screen for admins to see how async processing was going ,just in case anything was stuck. This might live in this queue for 20 seconds sometimes as it churns through creating everything. Then our business analysts sees this and has a brilliant idea...'I want to edit them' what do you mean edit them? 'I want to open up a queued request and change the values in it' Everything would be so much simpler is business analysts/product managers didn't exist or at least stopped having 'good ideas'
|
|
#
?
May 20, 2020 09:16
|
|
|
preemptive  for the disaster you are about to have visited upon youthis is why I hate workflow tooling. even if it starts simple ("we only need two forms") you will end up with a spiderweb disaster in no time
|
|
#
?
May 20, 2020 09:57
|
|
|
Powerful Two-Hander posted:preemptive As designed the workflow stuff is fine, you open the BPNM designer thingy we made and create the workflow, a process here, a decision there etc all great. When you create a record rules determine which workflow to choose. One of our resellers decided that the bit that picked the right workflow was a bit too much effort, so they create 1 workflow for all types of records for their customers (presumably using billable consultant hours). So instead of 20 workflows you have 1 workflow that reads from the record and goes through some hoops to make it work. We don't really know how they even do this as some of their workflows have thousands of stages and you cannot even open them in the editor, they must be doing it manually in SQL.
|
|
#
?
May 20, 2020 10:26
|
|
|
Nomnom Cookie posted:the obvious objection here being what about shared state? because thats what its about, doing some terrible poo poo with shared mutable state. ofc you know, but for the benefit of anyone who's not aware, big boy languages provide facilities to access databases, and that is where the shared mutable state goes. not in a blob squatting inside your process yah but then you get some guy who's not done anything outside of redux just moved to your mobile team and then it's like "content providers? sounds like someone reinvented redux. watch me now throw a fit if you don't go along with my plan to implement redux in loving android"
|
|
#
?
May 20, 2020 10:53
|
|
|
Chalks posted:if you do need to spin up a thread in your web request you can use QueueBackgroundWorkItem which creates a thread that the application will wait for when recycling instead of nuking it like a normal thread I would not rely on this for anything critical but its fine for best effort stuff.
|
|
#
?
May 20, 2020 12:28
|
|
|
Powerful Two-Hander posted:preemptive you can nip this one in the bud by doing design iterations on paper. A colleague of mine did this for designing a system for air ticket vendors and after a week of iterating designs they had one management felt comfortable with and the people who would actually use the system felt wouild cover their bases.
|
|
#
?
May 20, 2020 12:32
|
|
|
Boiled Water posted:you can nip this one in the bud by doing design iterations on paper. A colleague of mine did this for designing a system for air ticket vendors and after a week of iterating designs they had one management felt comfortable with and the people who would actually use the system felt wouild cover their bases. agreed. in my case, I've worked with my main business users for like 12 years now so I also have a lot of leeway with them and if I say "I know you say you want to have 25 sub statuses to provide 'MIS' but are you honestly going to populate them when you currently don't even keep the one single status you have up to date?" they usually listen or I just ignore them and do what I think makes sense and we iterate (or just deploy anyway #yolo #agile #neverwritespecs)
|
|
#
?
May 20, 2020 13:07
|
|
|
Shaggar posted:so wrt ASP.net specifically, afaik its all single threaded per request with threads taken from the pool. Long running tasks and spawning additional threads from within a request thread are definitely possible, but are strongly discouraged because the application might get nuked at any time and your task/thread will lose all its state. java servlets work the same way afaik yep, you just basically be careful with global state which you only encounter if you do it on purpose, like with a static cache or something registered as singleton in your di container Aramoro posted:This is where we made out first mistake, we added a screen for admins to see how async processing was going ,just in case anything was stuck. This might live in this queue for 20 seconds sometimes as it churns through creating everything. Then our business analysts sees this and has a brilliant idea...'I want to edit them' what do you mean edit them? 'I want to open up a queued request and change the values in it' lol literally had this happen before, so this time when i was tempted to build a screen to show the queues i changed my mind and built an email alert instead
|
|
#
?
May 20, 2020 13:54
|
|
|
abraham linksys posted:i still haven't managed to figure out erlang, i dunno, maybe it'd make me see the light on this poo poo, but i'm skeptical. i assume they have like... patterns for abstracting over state so you never actually want shared state and thus it doesn't matter, or something text me  Shaggar posted:depends on how the state is partitioned. If its chat data in a test app having it live in memory on your server is totally fine cause u aren't hosting multiple instances and you dont care if the data is lost when the process restarts. Chat apps (after IRC and ignoring a single instance corporate XMPP thing for a few hundred employees) are one of the app styles where you can't just keep state in one node in memory at a greater scale because if you have to contend with: - not disconnecting everyone at once when doing a rolling upgrade - not losing all in-flight messages that were not yet delivered - scaling things up is never always obvious: per user means your rooms/channels have to be distributed, per room/channel means you can get weird growth/scaling patterns and DMs are all distributed regardless any of the above, the biggest challenge of chat apps is always presence, which requires consistently tracking/polling all users and distributing that result to all other users, all the time.
|
|
#
?
May 20, 2020 14:18
|
|
|
Aramoro posted:Now all this record saving was written in command pattern so it's actually really easy to just queue them and do it asynchronously, as long as you validate the process before you queue it then it can't really fail, so all good. This is where we made out first mistake, we added a screen for admins to see how async processing was going ,just in case anything was stuck. This might live in this queue for 20 seconds sometimes as it churns through creating everything. Then our business analysts sees this and has a brilliant idea...'I want to edit them' what do you mean edit them? 'I want to open up a queued request and change the values in it' "no" also you gotta wonder what they see in that queue that makes them want to edit things, and whether the way that info is presented is any different from what they get elsewhere. It's possible that having them want to edit what's in the queue is just because the way it's presented triggers a use case they have but had no good way of conceptualizing before.
|
|
#
?
May 20, 2020 14:21
|
|
|
MononcQc posted:"no" in my case, without getting into the business-specific details, it was more "this message failed to validate or parse due to an easily fixable error, instead of bouncing a failure message back and forcing the entire process to start again at the source, let us just tweak the message and continue the process" when the process involves hitting external data sources at various stages you can kinda understand why they want to do this but there were obviously better solutions like applying more validations and parsing checks earlier in the process
|
|
#
?
May 20, 2020 14:40
|
|
|
MononcQc posted:"no" A bit of both really, what Cold on a Cob said and this. Like seeing something creates the Use Case for it. We've being doing it synchronously for 15 years but now they see the opportunity to break things in a way they had not considered. Another side is often they're tying to workaround another issue in the system. So instead of telling us the problem they'll say 'hey make this editable' or 'lets make this number field into text' without telling us why. It's almost always to workaround some behaviour in the system and this is the way they've thought of to it in the cheapest way possible, or so they think.
|
|
#
?
May 20, 2020 15:20
|
|
|
little bit of a panic attack. i'm making changes in our POS system after the vendor went out of business.
counting my blessings:
|
|
#
?
May 20, 2020 16:45
|
|
|
why the gently caress does every single customer have that one guy who insists on using vim for everything but they absolutely suck at using it  i've been watching this guy bungle around in a shared webex session for hours
|
|
#
?
May 20, 2020 16:49
|
|
|
don't you understand i'm so much faster because my finger motion is so EFFICIENT now!! *watches him struggle to remember how to enter a line break for 30 seconds*
|
|
#
?
May 20, 2020 16:53
|
|
|
|
| # ? Apr 24, 2024 09:39 |
|
|
PIZZA.BAT posted:why the gently caress does every single customer have that one guy who insists on using vim for everything but they absolutely suck at using it cargo culting after reading thousands of articles and books about super-productive 10xers
|
|
#
?
May 20, 2020 16:56
|
|