OK

Question

OK

arnaud.giuliani · Answer

well I have some diff in other stuff

arnaud.giuliani · Answer

then I have at minimum 220 files diffs stuck out tongue

arnaud.giuliani · Answer

When I have high structural impact like that I restart from the `koin core`project and after that I reanble the others modules

arnaud.giuliani · Answer

merging with PR via Github won t make it better I think

kpgalligan · Answer

Are the diffs changes from after my branch

arnaud.giuliani · Answer

I pushed your branch on the Koin repo

arnaud.giuliani · Answer

and try to merge to master just for try

kpgalligan · Answer

Got it might make sense if I take a look at that

arnaud.giuliani · Answer

yes I will make a tour

arnaud.giuliani · Answer

I will have some questions for you

kpgalligan · Answer

I pulled master from yesterday into my branch and merged I still need to review and move some things around so it s not done but I m working on it Created a new offshoot branch in my repo Will look at this more over the next couple days <https github com kpgalligan koin tree kpg kmp update>

kpgalligan · Answer

May make sense to resolve current diffs then push an experimental multiplatform release and target a big merge after 2 1 0

arnaud.giuliani · Answer

I will push a new Context Holder mechanism

kpgalligan · Answer

OK

arnaud.giuliani · Answer

Will help us have a single thread context and a global static context

arnaud.giuliani · Answer

the first one we would use ThreadLocal to store the context I believe you ve done like that in your branch

kpgalligan · Answer

It s not ThreadLocal per say If you try to request from a background thread it ll go to the main thread to get the value

arnaud.giuliani · Answer

ok there is 2 things then The Single Thread Context amp helpers to go back to this thread if you need

kpgalligan · Answer

Yeah so the way I wrote it if you just config Koin like normal without specifically allowing other thread access and you try to inject from another thread you ll get an exception You can configure components to be able to be accessed from a background thread The idea is if you access a component from another thread you have to freeze it and I really want that to be an explicit choice If you re going to reimplement the context access that s something to keep in mind The user should not be able to access something from another thread without somehow indicating that they re aware they re doing that If we just auto freeze it s not a great situation in my opinion

kpgalligan · Answer

To be clear though you are making a new implementation I was going to poke around doing the all thread version but if you re doing that I ll hold off

arnaud.giuliani · Answer

gt The user should not be able to access something from another thread without somehow indicating that they re aware they re doing that If we just auto freeze it s not a great situation in my opinion sure

arnaud.giuliani · Answer

I ll push my branch I will show you what I ve begin

arnaud.giuliani · Answer

arnaud.giuliani · Answer

and more specially <https github com InsertKoinIO koin tree context holder koin projects koin core src main kotlin org koin core context>

arnaud.giuliani · Answer

from that point we can setup any Kind of KoinContext

arnaud.giuliani · Answer

default is the Global one

arnaud.giuliani · Answer

what do you think about that

kpgalligan · Answer

I ll need to get back to you Meetings also launching this today <https twitter com kpgalligan status 1225471671248748551 s=20>

kpgalligan · Answer

Been super distracted

arnaud.giuliani · Answer

No problem slightly smiling face

arnaud.giuliani · Answer

it s already nice that we can chat and work about that slightly smiling face

arnaud.giuliani · Answer

I will dig into your code and ask you other stuff answer me later wink

kpgalligan · Answer

Yeah it would be great if we could sort out a test build around the time 1 3 70 goes out Will definitely be putting some time into this

arnaud.giuliani · Answer

whoo yeah slightly smiling face

arnaud.giuliani · Answer

I believe we can handle thread checking when we get the KoinContext component that is holding the Koin instance

arnaud.giuliani · Answer

this is the earliest point of access to Koin

arnaud.giuliani · Answer

and in a first approach I see as can I access Koin in Static can I access Koin in Thread Local

arnaud.giuliani · Answer

and then we get the right Koin instance and resolve it naturally because we are on the right thrad or a static context

arnaud.giuliani · Answer

I ve seen that you try to check that at several point BeanDefinition Koin get

arnaud.giuliani · Answer

I would be clearly optimis to try to place it at this first point

arnaud.giuliani · Answer

is the `MainIsolatedState` class a way to ensure stable reference in current thread

arnaud.giuliani · Answer

I guess there is no ThreadLocal stuff in KotlinNative

kpgalligan · Answer

Yeah It s all kind of in the following ```internal expect class MainIsolatedState lt T Any gt startVal T fun get T internal inline val lt T Any gt MainIsolatedState lt T gt value T get assertMainThread return get ```

kpgalligan · Answer

When accessing the value with ` value` it checks that you re on the main thread If so it calls ` get ` On JVM you could just use synchronized to make sure you re getting it safely but on native we actually need to make sure it s on the right thread

kpgalligan · Answer

```internal actual class MainIsolatedState lt T Any gt actual constructor startVal T private val stableRef = StableRef create startVal init startVal ensureNeverFrozen freeze actual fun get T = stableRef get ```

kpgalligan · Answer

`StableRef` essentially lets you get a pointer and you can pass that pointer around but when you call `stableRef get ` if you re not on the thread that state belongs to you have big problems

kpgalligan · Answer

Accessing that from calls that need to be on the main thread you can just call ` value` and there will be an exception if you re not on the main thread If the call should be able to be from another thread there s `mainOrBlock` which will block the caller and go to the main thread for that state if configured to allow that

kpgalligan · Answer

Without thinking about it too much those mechanisms could have slightly different implementations Instead of failing on some calls and switching threads on others there could be a set of functions with lambdas `accessConfig ` and `accessInvoke ` Something like that In the main thread instance `accessConfig` would throw if not in main thread and `accessInvoke` would block and move to main thread In multi thread `accessConfig` and `accessInvoke` would just wrap calls in synchronized although doing that just to inject could be problematic for performance

kpgalligan · Answer

Anyway still have to look at your code Busy couple days This went out yesterday actually using the Koin MP version I had in my branch <https github com touchlab KaMPKit>

arnaud.giuliani · Answer

make sense +1

arnaud.giuliani · Answer

I will keep you touch

kpgalligan · Answer

OK Sounds good

kpgalligan · Answer

Any updates over the weekend Will take a look if things are stable ish Was thinking instead of configuring background thread access on setup we could have different inject methods

arnaud.giuliani · Answer

didn t touch anything those days confused

arnaud.giuliani · Answer

I still believe that we can tackle KMP when we get Koin context

arnaud.giuliani · Answer

this is the most simple case I need to setup a CoffeeMakerAppMP to help me test the first things