proc = Process(loop) proc.spawn(args, ...) becomes: proc = Process.spawn(loop, args, ...) There is a slight anymmetry in uv_process_t handles: there is no uv_process_init function, it's internal and called by uv_spawn at the begining. So, we cannot initialize our handle in Process.__init__, only when spawn is called, which means that a workaround was required not to call uv_close in case a process object was initialized (in Python) but never spawned. This should make the interaction simpler.
They are rw properties which can be used to adjust the send and receive buffers respectively.
When Loop was subclassed, Subclass.default_loop() still returned a Loop instance, even if it wasn't created before. This patch fixes that. The avid readed may have noticed that this patch also removes the atexit handler which decref'd the default loop. Upon reading the documentation, it turns out is not safe to use any Python APIs at that stage, we just never got bitten by it until now, by chance.
Kernels usually round it up to the next power of 2, that is, 512. More on this: http://blog.dubbelboer.com/2012/04/09/syn-cookies.html
Fold both functions into a single one, which only supports bytes and sequences of bytes (where bytes == anything implementing the buffer protocol, that includes bytearray and memoryview) uv buffers are allocated on stack since uv_udp_send copuies them, so we save a malloc there
- Use a single function: write, which accepts only bytes or sequences of bytes (where bytes == any object implementing the buffer protocol, including bytearray and memoryview) - Pipe.write accepts an optional argument 'send_handle', which makes it behave as the previous write2 function - uv buffers are allocated on stack, sine uv_write copies them, so we also save a malloc there
Found with python compiled with --with-pydebug saghul: if the PYUV__PYREF flag is set then it's guaranteed that the object has a refcount >= 2. If the the flag is not set, however, it's possible that we arrive here with a refcount of 1, then the first Py_DECREF would free the object, and immediately after we'd check the flags of such dead object. I guess this never blew up IRL because nobody overwrites the memory, but when running with a debug build, memory is overwritten, precisely to help catch this kind of bugs. Nice catch @geertj!