--001a114741aec1bad3053f481b06
Content-Type: text/plain; charset=UTF-8
On 20 October 2016 at 09:35, Hallvard Breien Furuseth <
h.b.furus...@usit.uio.no> wrote:
>
> Hmm. Nevermind, it's probably better to leave that to the user.
> It gets ugly for a library to meddle with the current thread's
>
I wrote:
> And.. duh, we've forgotten mdb_copy without MDB_CP_COMPACT.
> I'll do it later if nobody beats me to it.
Hmm. Nevermind, it's probably better to leave that to the user.
It gets ugly for a library to meddle with the current thread's
signals. I.e. it must check if SIGPIPE was already
On 27/09/16 22:14, l...@cloudflare.com wrote:
>On 26 September 2016 at 20:48, Hallvard Breien Furuseth
> wrote:
>> I think we can skip sigwait() too since the thread will exit when done.
>> (...)
>
> That's what my initial patch did. At least on OS X this leads to the
>
On 26 September 2016 at 20:48, Hallvard Breien Furuseth
wrote:
> I think we can skip sigwait() too since the thread will exit when done.
> Then any pending signals are presumably dropped. (I suppose some OS
> could give them to another thread, but that goes against
On 25/09/16 20:16, l...@cloudflare.com wrote:
> * Do not check for pending SIGPIPE: since this is a new thread there can't
> be any
I think we can skip sigwait() too since the thread will exit when done.
Then any pending signals are presumably dropped. (I suppose some OS
could give them to
--94eb2c07d07472c185053d5903fe
Content-Type: text/plain; charset=UTF-8
I've updated the patch to be much simpler:
* Set pthread_sigmask in copythr and return an error in my->mc_error
* Do not check for pending SIGPIPE: since this is a new thread there can't
be any
The URL stays the same.
Full_Name: Lorenz Bauer
Version:
OS:
URL: https://gist.github.com/lmb/63189f83c5f00dd59c86f3c9bc07694d
Submission from: (NULL) (2606:4700:1000:8200:5530:fc35:2f95:4f31)
As per the discussion in [1] I'm providing a patch to block and handle SIGPIPE
in the copy thread used when performing a