Thread pools on the JVM should usually be divided into the following three categories:
- CPU-bound
- Blocking IO
- Non-blocking IO polling
Each of these categories has a different optimal configuration and usage pattern.
| public class Pager<I, O> { | |
| private static final Observable FINISH_SEQUENCE = Observable.never(); | |
| private PublishSubject<Observable<I>> pages; | |
| private Observable<I> nextPage = finish(); | |
| private Subscription subscription = Subscriptions.empty(); | |
| private final PagingFunction<I> pagingFunction; | |
| private final Func1<I, O> pageTransformer; |
| public static Action1<Throwable> crashOnError() { | |
| final Throwable checkpoint = new Throwable(); | |
| return throwable -> { | |
| StackTraceElement[] stackTrace = checkpoint.getStackTrace(); | |
| StackTraceElement element = stackTrace[1]; // First element after `crashOnError()` | |
| String msg = String.format("onError() crash from subscribe() in %s.%s(%s:%s)", | |
| element.getClassName(), | |
| element.getMethodName(), | |
| element.getFileName(), | |
| element.getLineNumber()); |
| #define BINKGL_LIST \ | |
| /* ret, name, params */ \ | |
| GLE(void, LinkProgram, GLuint program) \ | |
| GLE(void, GetProgramiv, GLuint program, GLenum pname, GLint *params) \ | |
| GLE(GLuint, CreateShader, GLenum type) \ | |
| GLE(void, ShaderSource, GLuint shader, GLsizei count, const GLchar* const *string, const GLint *length) \ | |
| GLE(void, CompileShader, GLuint shader) \ | |
| GLE(void, GetShaderiv, GLuint shader, GLenum pname, GLint *params) \ | |
| GLE(void, GetShaderInfoLog, GLuint shader, GLsizei bufSize, GLsizei *length, GLchar *infoLog) \ | |
| GLE(void, DeleteShader, GLuint shader) \ |
| # -*- encoding: utf-8 -*- | |
| import sublime | |
| import sublime_plugin | |
| class MinimapSetting(sublime_plugin.EventListener): | |
| def on_activated(self, view): | |
| show_minimap = view.settings().get('show_minimap') | |
| if show_minimap: |
| # OBJECTIVE: Install Arch Linux with encrypted root and swap filesystems and boot from UEFI. | |
| # Note this encrypted installation method, while perfectly correct and highly secure, CANNOT support encrypted /boot and | |
| # also CANNOT be subsequently converted to support an encrypted /boot!!! A CLEAN INSTALL will be required! | |
| # Therefore, if you want to have an encrypted /boot or will want an encrypted /boot system at some point in the future, | |
| # please ONLY follow my encrypted /boot installation guide, which lives here: |
| /* | |
| HotSwap shader sytem for MonoGame | |
| HotSwap code only exists for debug builds | |
| Edit paths to match your project | |
| Construct in your Initialize method | |
| Add shaders in LoadContent (or whenever) | |
| Call CheckForChanges in Update() or periodically however you like | |
| mgcb.exe usually located in C:\Program Files (x86)\MSBuild\MonoGame\v3.0\Tools | |
| */ |
| # ---------------------------------------------------------------------------------- | |
| # r u s t f m t - C O N F I G | |
| # ================================================================================== | |
| # | |
| # Version: 0.7.1 | |
| # Author : Robbepop <[email protected]> | |
| # | |
| # A predefined .rustfmt.toml file with all configuration options and their | |
| # associated description, possible values and default values for use in other | |
| # projects. |
In this example I am spinning up 2 web servers and 2 file servers using Terraform. During the provision process, Terraform will run a remote-exec script to bind the 4 new servers to the salt master server.
Substitute actual user and API key for SL_USERNAME and SL_API_KEY
export TF_VAR_slusername="SL_USERNAME"
export TF_VAR_slapikey="SL_API_KEY"
The libdispatch is one of the most misused API due to the way it was presented to us when it was introduced and for many years after that, and due to the confusing documentation and API. This page is a compilation of important things to know if you're going to use this library. Many references are available at the end of this document pointing to comments from Apple's very own libdispatch maintainer (Pierre Habouzit).
My take-aways are:
You should create very few, long-lived, well-defined queues. These queues should be seen as execution contexts in your program (gui, background work, ...) that benefit from executing in parallel. An important thing to note is that if these queues are all active at once, you will get as many threads running. In most apps, you probably do not need to create more than 3 or 4 queues.
Go serial first, and as you find performance bottle necks, measure why, and if concurrency helps, apply with care, always validating under system pressure. Reuse