You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bidirectional plugin authors (including deephaven.ui component authors) often have the need to submit work off-thread that will communicate with the actively connected client. We generally don't want to encourage making a new thread for each use case, so instead we should offer access to existing applicable threadpools.
In this case, the server already starts a set of threads, for "serial" and "concurrent" work. In the future we might introduce a "fast" option as well, for #3041. Typically, calls that will take an exclusive UGP lock should use the serial executor, and calls that will take the shared lock should use the concurrent executor. Calls that will not touch the update graph in any way (including no table data or operations, etc) at all might want to use the future "fast" executor.
Somewhat blocked on #4040, where ongoing refactoring will make it simpler to cleanly provide access to server threads after the python script session has been created.
The text was updated successfully, but these errors were encountered:
Provides access to server thread pools from python, enabling plugin or
dhui component authors to move work off-thread as appropriate, without
introducing their own threads.
Partial deephaven#4942
Provides access to server thread pools from python, enabling plugin or
dhui component authors to move work off-thread as appropriate, without
introducing their own threads.
Partial deephaven#4942
Provides access to server thread pools from python, enabling plugin or
dhui component authors to move work off-thread as appropriate, without
introducing their own threads. Later work will make use of the existing
server Scheduler.
Partial #4942
Bidirectional plugin authors (including deephaven.ui component authors) often have the need to submit work off-thread that will communicate with the actively connected client. We generally don't want to encourage making a new thread for each use case, so instead we should offer access to existing applicable threadpools.
In this case, the server already starts a set of threads, for "serial" and "concurrent" work. In the future we might introduce a "fast" option as well, for #3041. Typically, calls that will take an exclusive UGP lock should use the serial executor, and calls that will take the shared lock should use the concurrent executor. Calls that will not touch the update graph in any way (including no table data or operations, etc) at all might want to use the future "fast" executor.
Somewhat blocked on #4040, where ongoing refactoring will make it simpler to cleanly provide access to server threads after the python script session has been created.
The text was updated successfully, but these errors were encountered: