Sorting Through the Mio Mess

(Fletcher) #21

I wish I could multi-heart this. The FOSS world is somewhat like academia, but worse, in one respect: politics. This isn’t exactly bad, but it brings its own set of non-technical dependencies in the form of relations to keep up, considering how your project’s trajectory is going to affect theirs, etc.


(Fletcher) #22

Sorry @torkleyy I meant to respond to this. Depends on how we fix mio. Fixing it by just using async sockets is easy. Fixing it by using iocp is a little harder. Two is a bit less work than five, I think.

1 Like

(Thomas Schaller) #23

Okay, I see, thank you. So it seems to me that at this point we should communicate with the mio owner(s), so we can evaluate what the “overhead” of option 2 would be.


(Fletcher) #24

I’m not sure that would garner any useful information. The issue is known, as are the potential fixes; it is asked and answered multiple times in their issues. Someone just has to do it. The main problem seems to be that no one wants to deal with Windows.


(Jacob Kiesel) #25

Post is up: The constant cycle of rewriting and how we can put it to an end


(Khionu Sybiern) #26

Honestly, I’m surprised how no one was in favour of Option 4.

  1. Ideal performance on all systems. This allows Laminar to be viable for usage by people who do care about Windows performance. Decisions we make now will taint perspectives on people who might have used Amethyst later on, and corporations are slow to move technologically. We should be worried about giving them a bad image now.

  2. Least transition, to and from the solution. While we would have to maintain a separate implementation for Windows, it wouldn’t change our API, it wouldn’t change what we would have later in the future… it’s a temporary wooden column while we get the proper marble one redone, to keep the roof level.

1 Like

(David LeGare) #27

I guess I was effectively advocating for option 4. “Use mio on the platforms that it supports well, use an alternate approach on Windows” seems like a very reasonable solution where we only need to invest heavily in making improvements to the one platform that isn’t currently well supported.


(Lucio Franco) #28

It pretty much would require us to comply with the mio api anyways, meaning that it probably wouldn’t be much more work to just impl the windows side of mio. So the benefit of going wtih 4 seems a bit low to me.


(Khionu Sybiern) #29

The benefit is not committing code that hurts Windows performance. From what I understand, fixing the Mio Windows impl will take a while? We either let that block the Mio changes, or create a temporary fix, such as option 4. I feel that pushing code that hurts Windows performance is pretty far from acceptable.

So, it’s less of a benefit, and more that other options are more cost than gain, in the bigger picture.


(Lucio Franco) #30

We don’t actually know if it will break our implementation of laminar. I do think in an experimental stance its fine to push code that might be slower on one platform with the understanding that it will be fixed. I say this too because I don’t even think laminar and networking in amethyst is very usable atm. So by the time that is usable it will be fixed. To me under that premise its fine.

1 Like

(Khionu Sybiern) #31

I can’t speak as much for Laminar, but I think it is poor for us to treat Amethyst as experimental, even if it’s functionally as good as. It’s a lowering of standards, and it will slow down our progress in the bigger picture.


(Fletcher) #32

I cannot disagree more with this. We have no guarantees it will be fixed. Plus it goes against all of our espoused philosophical ideals for Amethyst and code quality in general. We do far too much of this “Well, it’ll be fixed some day, so fuck it” stuff.

1 Like