Dmitrii Kalianov

SQLite is itself non thread-safe w.r.t. single database handle (i.e., each thread should open its own handle to the database). So it does not make much sense to make the...

Thanks for the suggestion. I've added tracing-subscriber (at TRACE level) and got the following log output. It's intermixed with stdout output, so messages from println's are also there. [hyperreader.log](https://github.com/hyperium/hyper/files/8942952/hyperreader.log)

In the log I don't see any `release_connection_capacity` or `release_capacity`. By the code it seems that the connection receive window is being increased only when some stream has received data...

I had an idea (that I had not yet tried to implement): release connection capacity when stream is accepted or polled for the first time. This still provides some sort...

Hi! I have stopped doing any work on this project, unfortunately. So unless someone decides to take this project from me and maintain it, this bug will not be fixed....

Very interesting bug. Actually, even smaller code demonstrates it: (make-instance 'gtk:entry :secondary-icon-tooltip-text "some text") I'm trying to debug it

Seems to be a Gtk+ bug to me. Following C program also crashes: #include ``` int main (int argc, char *argv[]) { gtk_init(&argc, &argv); GtkEntry* entry; entry = (GtkEntry*)g_object_new(gtk_entry_get_type(), "secondary-icon-tooltip-text",...

Yes, its definitely Gtk+ bug. See https://bugzilla.gnome.org/show_bug.cgi?id=606103

Can you provide more detailed description of what happened? E.g., this happened in SLIME or in a console window; if it was SLIME, what commands were entered into REPL and...

The problems was that Gtk+ during initialization changes SIPIPE handler to SIGIGN and SBCL uses SIGPIPE to interrupt threads. I've commited the workaround, but this will need some more thought.