concurrency bug fixes/ improvements #4663
Conversation
|
The second commit seems to be neither a bug fix nor a concurrency improvement. |
|
It doesn't appear to be one as of now ;) Later when we create multiple clients per run of the executable, it's important that we can create multiple ide states, too. |
|
Right, as of now it is a random change :P As you know, I don't think the complexity that might be introduced by handling multiple clients at the same time should be handled within HLS. Perhaps if the complexity was encapsulated in a separate module / executable. |
|
Well this complexity is necessary if we ever want a single executable with multiple clients which I think is actually required to make it feasible at all, mainly wrt memory footprint. |
|
I'll create a ticket. |
|
@fendor so whether or not I create the ticket, are these changes controversial? |
|
No, these changes are not controversial |
This is the right thing to do because othewise it is not possible to create new ideStates in a single instance of the executable. This will be useful if the hls executable is supposed to talk to multiple clients and lives beyond a single client disconnecting.
MangoIV
force-pushed
the
mangoiv/concurrency-bug-fixes
branch
from
dc9b008 to
5e7ee92
Compare
Previously, when there was no shutdown message by a client and the client disconnected, resulting in the handlers to be GC'd the race that was supposed to free resources for the HieDB & co. would throw a hard error talking about the MVar being unreachable. We would like to instead finish gracefully because finishing the race as soon as the MVar was GC'd is the right thing to do anyway.
MangoIV
force-pushed
the
mangoiv/concurrency-bug-fixes
branch
from
5e7ee92 to
6696657
Compare
|
@fendor I think I applied all of your suggestions |
|
Ah shoot forgot to adjust the wrapper here. |
Hi. I have two concurrency bug fixes/ improvements that pave the way towards multi client haskell-language-server.
[fix] don't bake ide state mvar into setup and getIdeState
This is the right thing to do because othewise it is not possible to
create new ideStates in a single instance of the executable. This will
be useful if the hls executable is supposed to talk to multiple clients
and lives beyond a single client disconnecting
[fix] don't throw hard errors when no shutdown message is handled
Previously, when there was no shutdown message by a client and the
client disconnected, resulting in the handlers to be GC'd the race that
was supposed to free resources for the HieDB & co. would throw a hard
error talking about the MVar being unreachable. We would like to instead
finish gracefully because finishing the race as soon as the MVar was
GC'd is the right thing to do anyway.