Re: (ITS#8504) LDMB: Return EPIPE from mdb_env_copyfd2 instead abort on SIGPIPE

2016-10-20 Thread lmb
--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 >

Re: (ITS#8504) LDMB: Return EPIPE from mdb_env_copyfd2 instead abort on SIGPIPE

2016-10-20 Thread h . b . furuseth
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

Re: (ITS#8504) LDMB: Return EPIPE from mdb_env_copyfd2 instead abort on SIGPIPE

2016-10-20 Thread h . b . furuseth
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 >

Re: (ITS#8504) LDMB: Return EPIPE from mdb_env_copyfd2 instead abort on SIGPIPE

2016-09-26 Thread h . b . furuseth
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

Re: (ITS#8504) LDMB: Return EPIPE from mdb_env_copyfd2 instead abort on SIGPIPE

2016-09-25 Thread lmb
--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.