emarsden / pg-el Goto Github PK

Hi,

I have encountered an intermittent race condition in my use of the library. Sometimes, when pg-exec is in the main loop reading in DataRow result tuples, it will call pg-read-tuple (which then calls pg-read-chars) while only part of the data for this row has been loaded into the process buffer. pg-read-chars will then raise an args-out-of-range error as it attempts to read a substring from the process buffer beyond the current end of the buffer.

The simplest workaround I found is to precede the buffer-substring call in pg-read-chars with a call to accept-process-output, using the same logic as in the pg-read-char function. pg-read-chars becomes:

(defun pg-read-chars (connection count)
  (let* ((process (pgcon-process connection))
         (start (pgcon-position connection))
         (end (+ start count)))
    (accept-process-output)
    (prog1 (with-current-buffer (process-buffer process)
             ;; wait for new output, if necessary
             (when (> end (point-max))
               (accept-process-output process 5))
             (buffer-substring start end))
      (setf (pgcon-position connection) end))))

-- Sam

I noticed commit 2ec40a4 is tagged as v0.19. But should it be commit dbdae7d?

If at all possible, a repository used to maintain an Emacs package should not bundle any third-party libraries.

Bundling external dependencies might not cause any issues for users who install the package from Melpa, because packages distributed there can filter out unwanted libraries. But some people (including myself) run packages directly from their repositories (e.g., because that makes it much easier to contribute).

For such users the bundled library may end up on the load-path, possibly before the independently installed (or built-in) upstream version. As a result some outdated version can end up being loaded and that can be very confusing and hard to debug.

I recommend that you never bundle any third-party libraries. If that is not possible, I recommend that you put those libraries in a separate directory, alongside a file named .nosearch. The existence of this file instructs some tools (such as normal-top-level-add-subdirs-to-load-path and the tools that I use to maintain the Emacsmirror) to ignore the containing directory.

Thanks for considering this!

_{I have written similar messages many many times so I now use a template. I try to adjust it to match each individual case but it might still not apply 100% in all cases.}