-
Notifications
You must be signed in to change notification settings - Fork 5k
[DO NOT MERGE] fan-in for sockets experiment #57551
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So both 3 and 13 in your example of 10 concurrent would still write into the same socket just through a channel so even if they're running concurrently it won't mess us objects tied to the socket such as mapper or writer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
right, they will both post to the same channel, and per socket the write coroutine will tear down the channel 1-at-a-time
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens when:
- Two threads writing to the same channel?
- Channel at capacity
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
kotlin will handle the contention; i'm not sure of the exact way it's handled, but it's supposed to be more efficient than java locks
at capacity the writing coroutine will suspend until the channel clears
997c867 to
83a7a56
Compare
|
The latest updates on your projects. Learn more about Vercel for Git βοΈ
|
83a7a56 to
e9840d2
Compare
| lateinit var socketOutputConsumer: UnixDomainSocketOutputConsumer | ||
| override suspend fun acceptAsync(recordData: ObjectNode, changes: Map<Field, FieldValueChange>?, totalNum: Int?, num: Long?) { | ||
| outputConsumer.getSocketConsumer(num!!.toInt()).acceptAsync(recordData, stream.namespace ?: "", stream.name) | ||
| if (::socketOutputConsumer.isInitialized.not()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is threadsafe b/c this is a suspend fun; the init state of socketOutputConsumer might not be synced across threads if the coroutine changes threads?
58993f5 to
c56b750
Compare
e29f22e to
8600b3c
Compare
f47ba81 to
241a5c9
Compare
What
How
Review guide
User Impact
Can this PR be safely reverted and rolled back?