Re: Escaping from blocked send() reprised.

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: andres(at)2ndquadrant(dot)com
Cc: hlinnakangas(at)vmware(dot)com, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Escaping from blocked send() reprised.
Date: 2014-10-02 10:11:21
Message-ID: 20141002.191121.13329779.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2014-10-02 10:50:27 Re: pgbench throttling latency limit
Previous Message Andres Freund 2014-10-02 09:50:14 Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)