Re: Escaping from blocked send() reprised. - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: Escaping from blocked send() reprised.
Date
Msg-id 20141002.191121.13329779.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: Escaping from blocked send() reprised.  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Escaping from blocked send() reprised.
List pgsql-hackers
Hi,

> > > But this is imo prohibitive. Yes, we're doing it for a long while. But
> > > no, that's not ok. It actually prompoted me into prototyping the latch
> > > thing (in some other thread). I don't think existing practice justifies
> > > expanding it further.
> > 
> > I see, in that case, this approach seems basically
> > applicable. But if I understand correctly, this patch seems not
> > to return out of the openssl code even when latch was found to be
> > set in secure_raw_write/read.
> 
> Correct. That's why I think it's the way forward. There's several
> problems now where the inability to do real things while reading/writing
> is a problem.
> 
> >  I tried setting errno = ECONNRESET
> > and it went well but seems a bad deed.
> 
> Where and why did you do that?

The patch of this message.

http://www.postgresql.org/message-id/20140828.214704.93968088.horiguchi.kyotaro@lab.ntt.co.jp

The reason for setting errno (instead of a variable for it) is to
trick openssl (or my_socck_write? I've forgot it..) into
recognizing as if the underneath send(2) have returned with any
uncontinueable error so it cannot be any of continueable errnos
(EINTR/EWOULDBLOCK/EAGAIN). Iy my faint memory, only avoiding
BIO_set_retry_write() in my_sock_write() dosn't work as expected
but it might be enough that my_sock_write returns -1 and doesn't
set BIO_set_retry_write().

The reason why ECONNNRESET is any of other errnos possible for
send(2)(*1) doesn't seem to fit the real situation, and the
blocked situation seems similar to resetted connection from the
view that it cannot continue to work due to external condition,
and it is used in be_tls_write() in a similary way.

Come to think of it, setting ECONNRESET is not so evil?


> > secure_raw_write(Port *port, const void *ptr, size_t len)
> > {
> >   n = send(port->sock, ptr, len, 0);
> >   
> >   if (!port->noblock && n < 0 && (errno == EWOULDBLOCK || errno == EAGAIN))
> >   {
> >     w = WaitLatchOrSocket(&MyProc->procLatch, ...
> > 
> >     if (w & WL_LATCH_SET)
> >     {
> >     ResetLatch(&MyProc->procLatch);
> >         /*
> >         * Force a return, so interrupts can be processed when not
> >         * (possibly) underneath a ssl library.
> >         */
> >         errno = EINTR;
> >         (return n;  // n is negative)
> > 
> > 
> > my_sock_write(BIO *h, const char *buf, int size)
> > {
> >   res = secure_raw_write(((Port *) h->ptr), buf, size);
> >   BIO_clear_retry_flags(h);
> >   if (res <= 0)
> >   {
> >     if (errno == EINTR || errno == EWOULDBLOCK || errno == EAGAIN)
> >     {
> >       BIO_set_retry_write(h);
> 
> Hm, this seems, besides one comment, the code from the last patch in my
> series. Do you have a particular question about it?

I didn't have a particluar qustion about it. This is cited only
in order to show the route to retrying.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)
Next
From: Heikki Linnakangas
Date:
Subject: Re: pgbench throttling latency limit