Re: [HACKERS] Escaping from blocked send() reprised.

2015-01-13 Thread Andres Freund
On 2015-01-12 00:40:50 +0100, Andres Freund wrote: Fixed in what I've since pushed (as Heikki basically was ok with the patch sent a couple months back, modulo some fixes)... I'd not actually pushed that patch... I had pushed some patches (barriers, atomics), but had decided to hold off on

Re: [HACKERS] Escaping from blocked send() reprised.

2015-01-11 Thread Noah Misch
On Mon, Jan 12, 2015 at 01:45:41AM +0100, Andres Freund wrote: On 2015-01-11 19:37:53 -0500, Noah Misch wrote: I recommend either (a) taking no action or (b) adding a regression test verifying WaitLatchOrSocket() conformance in this scenario. Do you have a good idea how to test b) save a C

Re: [HACKERS] Escaping from blocked send() reprised.

2015-01-11 Thread Andres Freund
On 2015-01-11 19:37:53 -0500, Noah Misch wrote: I recommend either (a) taking no action or (b) adding a regression test verifying WaitLatchOrSocket() conformance in this scenario. Do you have a good idea how to test b) save a C function in regress.c that does what your test does using latches?

Re: [HACKERS] Escaping from blocked send() reprised.

2015-01-11 Thread Robert Haas
On Sat, Jan 10, 2015 at 11:35 AM, Andres Freund and...@2ndquadrant.com wrote: Interesting. I dimly remembered you mentioning this, that's how I rediscovered this message. Do you remember any details? No, not really. My guess that's not so much the overhead of the latch itself, but the lack

Re: [HACKERS] Escaping from blocked send() reprised.

2015-01-11 Thread Noah Misch
On Mon, Jan 12, 2015 at 12:40:50AM +0100, Andres Freund wrote: On 2015-01-11 16:36:07 -0500, Noah Misch wrote: On Sat, Jan 10, 2015 at 03:25:42AM +0100, Andres Freund wrote: 0001-Allow-latches-to-wait-for-socket-writability-without.patch Imo pretty close to commit and can be

Re: [HACKERS] Escaping from blocked send() reprised.

2015-01-11 Thread Noah Misch
On Sat, Jan 10, 2015 at 03:25:42AM +0100, Andres Freund wrote: 0001-Allow-latches-to-wait-for-socket-writability-without.patch Imo pretty close to commit and can be committed independently. The key open question is whether all platforms of interest can reliably detect end-of-file when

Re: [HACKERS] Escaping from blocked send() reprised.

2015-01-11 Thread Andres Freund
On 2015-01-11 16:47:53 -0500, Robert Haas wrote: My guess that's not so much the overhead of the latch itself, but the lack of the directed wakeup stuff the OS provides for semaphores. That's possible. On Sat, Jan 10, 2015 at 11:35 AM, Andres Freund and...@2ndquadrant.com wrote:

Re: [HACKERS] Escaping from blocked send() reprised.

2015-01-11 Thread Andres Freund
On 2015-01-11 16:36:07 -0500, Noah Misch wrote: On Sat, Jan 10, 2015 at 03:25:42AM +0100, Andres Freund wrote: 0001-Allow-latches-to-wait-for-socket-writability-without.patch Imo pretty close to commit and can be committed independently. The key open question is whether all platforms

Re: [HACKERS] Escaping from blocked send() reprised.

2015-01-10 Thread Andres Freund
On 2014-09-04 08:49:22 -0400, Robert Haas wrote: On Tue, Sep 2, 2014 at 3:01 PM, Andres Freund and...@2ndquadrant.com wrote: I'm slightly worried about the added overhead due to the latch code. In my implementation I only use latches after a nonblocking read, but still. Every

Re: [HACKERS] Escaping from blocked send() reprised.

2015-01-09 Thread Andres Freund
On 2014-11-17 18:22:54 +0300, Alex Shulgin wrote: Andres Freund and...@2ndquadrant.com writes: I've invested some more time in this: 0002 now makes sense on its own and doesn't change anything around the interrupt handling. Oh, and it compiles without 0003. In this patch, the

Re: [HACKERS] Escaping from blocked send() reprised.

2015-01-08 Thread Andres Freund
On 2014-10-03 16:26:35 +0200, Andres Freund wrote: On 2014-10-03 17:12:18 +0300, Heikki Linnakangas wrote: 0002 now makes sense on its own and doesn't change anything around the interrupt handling. Oh, and it compiles without 0003. WaitLatchOrSocket() can throw an error, so it's

Re: [HACKERS] Escaping from blocked send() reprised.

2014-12-16 Thread Kyotaro HORIGUCHI
Hello, On 2014-12-15 18:19:26 +0900, Kyotaro HORIGUCHI wrote: Since I don't have clear idea how to promote this, I will remake and be back with new patch based on Andres' for patches. Do my patches miss any functionality you want? The patch satisfies what I want, as I said upthread. What

Re: [HACKERS] Escaping from blocked send() reprised.

2014-12-15 Thread Kyotaro HORIGUCHI
Since I don't have clear idea how to promote this, I will remake and be back with new patch based on Andres' for patches. Hmm.. Sorry for my stupidity. Why is that necessary? It seems really rather wrong to make BIO_set_retry_write() dependant on ProcDiePending? Especially as, at least

Re: [HACKERS] Escaping from blocked send() reprised.

2014-12-15 Thread Andres Freund
On 2014-12-15 18:19:26 +0900, Kyotaro HORIGUCHI wrote: Since I don't have clear idea how to promote this, I will remake and be back with new patch based on Andres' for patches. Do my patches miss any functionality you want? Greetings, Andres Freund -- Andres Freund

Re: [HACKERS] Escaping from blocked send() reprised.

2014-12-14 Thread Michael Paquier
On Thu, Oct 30, 2014 at 10:27 PM, Heikki Linnakangas hlinnakan...@vmware.com wrote: On 10/03/2014 06:29 PM, Heikki Linnakangas wrote: [blah] About patch 3: Looking closer, this design still looks OK to me. As you said yourself, the comments need some work (e.g. the step 5. in the top comment

Re: [HACKERS] Escaping from blocked send() reprised.

2014-11-17 Thread Alex Shulgin
Andres Freund and...@2ndquadrant.com writes: I've invested some more time in this: 0002 now makes sense on its own and doesn't change anything around the interrupt handling. Oh, and it compiles without 0003. In this patch, the endif appears to be misplaced in PostgresMain: + if

Re: [HACKERS] Escaping from blocked send() reprised.

2014-10-30 Thread Heikki Linnakangas
On 10/03/2014 06:29 PM, Heikki Linnakangas wrote: On 10/03/2014 05:26 PM, Andres Freund wrote: On 2014-10-03 17:12:18 +0300, Heikki Linnakangas wrote: On 09/28/2014 01:54 AM, Andres Freund wrote: 0003 Sinval/notify processing got simplified further. There really isn't any need for

Re: [HACKERS] Escaping from blocked send() reprised.

2014-10-30 Thread Andres Freund
On 2014-10-30 15:27:13 +0200, Heikki Linnakangas wrote: The comment on PGPROC.procLatch in storage/proc.h says just this: Latch procLatch; /* generic latch for process */ This needs a lot more explaining. It's now used by signal handlers to interrupt a read or

Re: [HACKERS] Escaping from blocked send() reprised.

2014-10-10 Thread Kyotaro HORIGUCHI
Hmm.. Sorry for my stupidity. Why is that necessary? It seems really rather wrong to make BIO_set_retry_write() dependant on ProcDiePending? Especially as, at least in my testing, it's not even required because the be_tls_write() can just check the error properly? I mistook the previous

Re: [HACKERS] Escaping from blocked send() reprised.

2014-10-09 Thread Andres Freund
On 2014-10-09 14:06:35 +0900, Kyotaro HORIGUCHI wrote: Hello, simplly inhibit set retry flag when ProcDiePending in my_sock_write seems enough. But it returns with SSL_ERROR_SYSCALL not SSL_ERROR_WANT_WRITE so I modified the patch 4 as the attached patch. Why is that necessary? It seems

Re: [HACKERS] Escaping from blocked send() reprised.

2014-10-08 Thread Kyotaro HORIGUCHI
Hello, simplly inhibit set retry flag when ProcDiePending in my_sock_write seems enough. But it returns with SSL_ERROR_SYSCALL not SSL_ERROR_WANT_WRITE so I modified the patch 4 as the attached patch. Finally, the attached patch works as expected with Andres's patch 1-3. regards, -- Kyotaro

Re: [HACKERS] Escaping from blocked send() reprised.

2014-10-05 Thread Andres Freund
On 2014-10-03 18:29:23 +0300, Heikki Linnakangas wrote: On 10/03/2014 05:26 PM, Andres Freund wrote: On 2014-10-03 17:12:18 +0300, Heikki Linnakangas wrote: On 09/28/2014 01:54 AM, Andres Freund wrote: 0003 Sinval/notify processing got simplified further. There really isn't any need for

Re: [HACKERS] Escaping from blocked send() reprised.

2014-10-03 Thread Heikki Linnakangas
On 09/28/2014 01:54 AM, Andres Freund wrote: I've invested some more time in this: Thanks! In 0001, the select() codepath will not return (WL_SOCKET_READABLE | WL_SOCKET_WRITEABLE) on EOF or error, like the comment says and like the poll() path does. It only sets WL_SOCKET_READABLE if

Re: [HACKERS] Escaping from blocked send() reprised.

2014-10-03 Thread Andres Freund
Hi, On 2014-10-03 17:12:18 +0300, Heikki Linnakangas wrote: On 09/28/2014 01:54 AM, Andres Freund wrote: I've invested some more time in this: Thanks! In 0001, the select() codepath will not return (WL_SOCKET_READABLE | WL_SOCKET_WRITEABLE) on EOF or error, like the comment says and like

Re: [HACKERS] Escaping from blocked send() reprised.

2014-10-03 Thread Heikki Linnakangas
On 10/03/2014 05:26 PM, Andres Freund wrote: On 2014-10-03 17:12:18 +0300, Heikki Linnakangas wrote: On 09/28/2014 01:54 AM, Andres Freund wrote: 0003 Sinval/notify processing got simplified further. There really isn't any need for DisableNotifyInterrupt/DisableCatchupInterrupt

Re: [HACKERS] Escaping from blocked send() reprised.

2014-10-02 Thread Kyotaro HORIGUCHI
Sorry, I missed this message and only cought up when reading your CF status mail. I've attached three patches: Could let me know how to get the CF status mail? I think he meant this email I sent last weekend: http://www.postgresql.org/message-id/542672d2.3060...@vmware.com I see,

Re: [HACKERS] Escaping from blocked send() reprised.

2014-10-02 Thread Kyotaro HORIGUCHI
Hello, I propose the attached patch. It adds a new flag ImmediateDieOK, which is a weaker form of ImmediateInterruptOK that only allows handling a pending die-signal in the signal handler. Robert, others, do you see a problem with this? Per se I don't have a problem with it. There

Re: [HACKERS] Escaping from blocked send() reprised.

2014-10-02 Thread Andres Freund
On 2014-10-02 17:47:39 +0900, Kyotaro HORIGUCHI wrote: Hello, I propose the attached patch. It adds a new flag ImmediateDieOK, which is a weaker form of ImmediateInterruptOK that only allows handling a pending die-signal in the signal handler. Robert, others, do you see a

Re: [HACKERS] Escaping from blocked send() reprised.

2014-10-02 Thread Kyotaro HORIGUCHI
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

Re: [HACKERS] Escaping from blocked send() reprised.

2014-09-30 Thread Kyotaro HORIGUCHI
Thank you for reviewing. I'll look close to the patch tomorrow. I must say this scares the heck out of me. The current code goes through some trouble to not throw an error while in a recv() send(). For example, you removed the DoingCommandRead check from prepare_for_client_read(). There's an

Re: [HACKERS] Escaping from blocked send() reprised.

2014-09-30 Thread Kyotaro HORIGUCHI
Wow, thank you for the patch. 0001: Allows WaitLatchOrSocket(WL_WRITABLE) without WL_READABLE. I've tested the poll() and select() implementations on linux and blindly patched up windows. 0002: Put the socket the backend uses to communicate with the client into

Re: [HACKERS] Escaping from blocked send() reprised.

2014-09-30 Thread Kyotaro HORIGUCHI
By the way, Sorry, I missed this message and only cought up when reading your CF status mail. I've attached three patches: Could let me know how to get the CF status mail? regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Escaping from blocked send() reprised.

2014-09-30 Thread Andres Freund
On 2014-09-26 21:02:16 +0300, Heikki Linnakangas wrote: I propose the attached patch. It adds a new flag ImmediateDieOK, which is a weaker form of ImmediateInterruptOK that only allows handling a pending die-signal in the signal handler. Robert, others, do you see a problem with this? Per

Re: [HACKERS] Escaping from blocked send() reprised.

2014-09-29 Thread Andres Freund
On 2014-09-28 00:54:21 +0200, Andres Freund wrote: On 2014-09-27 21:12:43 +0200, Andres Freund wrote: On 2014-09-03 15:09:54 +0300, Heikki Linnakangas wrote: Sorry, I missed this message and only cought up when reading your CF status mail. I've attached three patches: 0001: Allows

Re: [HACKERS] Escaping from blocked send() reprised.

2014-09-27 Thread Andres Freund
On 2014-09-03 15:09:54 +0300, Heikki Linnakangas wrote: On 09/03/2014 12:23 AM, Andres Freund wrote: On 2014-09-02 17:21:03 -0400, Tom Lane wrote: Heikki Linnakangas hlinnakan...@vmware.com writes: I was going to suggest using WaitLatchOrSocket instead of sleeping in 1 second increment, but I

Re: [HACKERS] Escaping from blocked send() reprised.

2014-09-26 Thread Heikki Linnakangas
On 09/09/2014 01:31 PM, Kyotaro HORIGUCHI wrote: Hi, I added and edited some comments. Sorry, It tha patch contains a silly bug. Please find the attatched one. I must say this scares the heck out of me. The current code goes through some trouble to not throw an error while in a recv()

Re: [HACKERS] Escaping from blocked send() reprised.

2014-09-17 Thread Kyotaro HORIGUCHI
Sorry for the mistake... At Wed, 10 Sep 2014 18:53:03 +0300, Heikki Linnakangas hlinnakan...@vmware.com wrote in 541073df.70...@vmware.com Wrong thread... On 09/10/2014 03:04 AM, Kyotaro HORIGUCHI wrote: Hmm. Sorry, I misunderstood the specification. You approach that coloring tokens

Re: [HACKERS] Escaping from blocked send() reprised.

2014-09-10 Thread Heikki Linnakangas
Wrong thread... On 09/10/2014 03:04 AM, Kyotaro HORIGUCHI wrote: Hmm. Sorry, I misunderstood the specification. You approach that coloring tokens seems right, but you have broken the parse logic by adding your code. Other than the mistakes others pointed, I found that - non-SQL-ident like

Re: [HACKERS] Escaping from blocked send() reprised.

2014-09-09 Thread Kyotaro HORIGUCHI
Hi, I added and edited some comments. Sorry, It tha patch contains a silly bug. Please find the attatched one. regards, -- Kyotaro Horiguchi NTT Open Source Software Center From eb91a7c91e1fd3b24bf5bff0eb885f1c3d274637 Mon Sep 17 00:00:00 2001 From: Kyotaro Horiguchi

Re: [HACKERS] Escaping from blocked send() reprised.

2014-09-09 Thread Kyotaro HORIGUCHI
Hmm. Sorry, I misunderstood the specification. You approach that coloring tokens seems right, but you have broken the parse logic by adding your code. Other than the mistakes others pointed, I found that - non-SQL-ident like tokens are ignored by their token style, quoted or not, so

Re: [HACKERS] Escaping from blocked send() reprised.

2014-09-05 Thread Kyotaro HORIGUCHI
Hello, - This patch introduced redundant socket emulation for win32 backend but win32 bare socket for Port is already nonblocking as described so it donsn't seem to be a serious problem on performance. Addition to it, since I don't know the reason why win32/socket.c provides

Re: [HACKERS] Escaping from blocked send() reprised.

2014-09-05 Thread Kyotaro HORIGUCHI
Hello, attached is the new-and-far-simple version of this patch. It no longer depends on win32 nonblocking patch since the socket is in blocking mode again. On 08/28/2014 03:47 PM, Kyotaro HORIGUCHI wrote: - Preventing protocol violation. To prevent protocol violation, secure_write sets

Re: [HACKERS] Escaping from blocked send() reprised.

2014-09-05 Thread Kyotaro HORIGUCHI
Sorry, It tha patch contains a silly bug. Please find the attatched one. Hello, attached is the new-and-far-simple version of this patch. It no longer depends on win32 nonblocking patch since the socket is in blocking mode again. On 08/28/2014 03:47 PM, Kyotaro HORIGUCHI wrote: -

Re: [HACKERS] Escaping from blocked send() reprised.

2014-09-04 Thread Robert Haas
On Tue, Sep 2, 2014 at 3:01 PM, Andres Freund and...@2ndquadrant.com wrote: I'm slightly worried about the added overhead due to the latch code. In my implementation I only use latches after a nonblocking read, but still. Every WaitLatchOrSocket() does a drainSelfPipe(). I wonder if that can

Re: [HACKERS] Escaping from blocked send() reprised.

2014-09-04 Thread Heikki Linnakangas
On 09/04/2014 03:49 PM, Robert Haas wrote: On Tue, Sep 2, 2014 at 3:01 PM, Andres Freund and...@2ndquadrant.com wrote: I'm slightly worried about the added overhead due to the latch code. In my implementation I only use latches after a nonblocking read, but still. Every WaitLatchOrSocket() does

Re: [HACKERS] Escaping from blocked send() reprised.

2014-09-04 Thread Robert Haas
On Thu, Sep 4, 2014 at 9:05 AM, Heikki Linnakangas hlinnakan...@vmware.com wrote: Hmm. Perhaps we should call drainSelfPipe() only after poll/select returns saying that there is something in the self-pipe. That would be a win assuming it's more common for the self-pipe to be empty. Couldn't

Re: [HACKERS] Escaping from blocked send() reprised.

2014-09-04 Thread Heikki Linnakangas
On 09/04/2014 04:37 PM, Robert Haas wrote: Hrm. So we'd have to block SIGUSR1, check the flag, then use pselect() to temporarily unblock SIGUSR1 and wait, then on return again unblock SIGUSR1? Doesn't seem very appealing. I think changing the signal mask is fast on Linux, but quite slow on at

Re: [HACKERS] Escaping from blocked send() reprised.

2014-09-04 Thread Robert Haas
On Thu, Sep 4, 2014 at 9:53 AM, Heikki Linnakangas hlinnakan...@vmware.com wrote: On 09/04/2014 04:37 PM, Robert Haas wrote: Hrm. So we'd have to block SIGUSR1, check the flag, then use pselect() to temporarily unblock SIGUSR1 and wait, then on return again unblock SIGUSR1? Doesn't seem very

Re: [HACKERS] Escaping from blocked send() reprised.

2014-09-03 Thread Heikki Linnakangas
On 09/03/2014 12:23 AM, Andres Freund wrote: On 2014-09-02 17:21:03 -0400, Tom Lane wrote: Heikki Linnakangas hlinnakan...@vmware.com writes: I was going to suggest using WaitLatchOrSocket instead of sleeping in 1 second increment, but I see that WaitLatchOrSocket() doesn't currently support

Re: [HACKERS] Escaping from blocked send() reprised.

2014-09-02 Thread Heikki Linnakangas
On 08/28/2014 03:47 PM, Kyotaro HORIGUCHI wrote: To make the code mentioned above (Patch 0002) tidy, rewrite the socket emulation code for win32 backends so that each socket can have its own non-blocking state. (patch 0001) The first patch that makes non-blocking sockets behave more

Re: [HACKERS] Escaping from blocked send() reprised.

2014-09-02 Thread Heikki Linnakangas
On 08/28/2014 03:47 PM, Kyotaro HORIGUCHI wrote: - Preventing protocol violation. To prevent protocol violation, secure_write sets ClientConnectionLost when SIGTERM detected, then internal_flush() and ProcessInterrupts() follow the instruction. Oh, hang on. Now that I look at

Re: [HACKERS] Escaping from blocked send() reprised.

2014-09-02 Thread Andres Freund
On 2014-09-02 21:46:29 +0300, Heikki Linnakangas wrote: I was going to suggest using WaitLatchOrSocket instead of sleeping in 1 second increment, but I see that WaitLatchOrSocket() doesn't currently support waiting for a socket to become writeable, without also waiting for it to become

Re: [HACKERS] Escaping from blocked send() reprised.

2014-09-02 Thread Andres Freund
On 2014-09-02 21:01:44 +0200, Andres Freund wrote: I've actually been working on a patch to make the whole interaction with the client using sockets. The reason I started so is that we lots of far to complex stuff in signal handlers, and using a latch would allow us to instead interrupt

Re: [HACKERS] Escaping from blocked send() reprised.

2014-09-02 Thread Tom Lane
Heikki Linnakangas hlinnakan...@vmware.com writes: I was going to suggest using WaitLatchOrSocket instead of sleeping in 1 second increment, but I see that WaitLatchOrSocket() doesn't currently support waiting for a socket to become writeable, without also waiting for it to become readable.

Re: [HACKERS] Escaping from blocked send() reprised.

2014-09-02 Thread Andres Freund
On 2014-09-02 17:21:03 -0400, Tom Lane wrote: Heikki Linnakangas hlinnakan...@vmware.com writes: I was going to suggest using WaitLatchOrSocket instead of sleeping in 1 second increment, but I see that WaitLatchOrSocket() doesn't currently support waiting for a socket to become writeable,

Re: [HACKERS] Escaping from blocked send() reprised.

2014-08-28 Thread Kyotaro HORIGUCHI
Hello, sorry for the dazed reply in the previous mail. I made revised patch for this issue. Attached patches are following, - 0001_Revise_socket_emulation_for_win32_backend.patch Revises socket emulation on win32 backend so that each socket can have its own blocking mode state. -

Re: [HACKERS] Escaping from blocked send() reprised.

2014-08-26 Thread Kyotaro HORIGUCHI
Sorry, I was absorbed by other tasks.. Thank you for reviewing thiis. On 07/01/2014 06:26 AM, Kyotaro HORIGUCHI wrote: At Mon, 30 Jun 2014 11:27:47 -0400, Robert Haas robertmh...@gmail.com wrote in CA+TgmoZfcGzAEmtbyoCe6VdHnq085x+ox752zuJ2AKN=wc8...@mail.gmail.com 1. I think it's the

Re: [HACKERS] Escaping from blocked send() reprised.

2014-08-26 Thread Heikki Linnakangas
On 08/26/2014 09:17 AM, Kyotaro HORIGUCHI wrote: but I don't think we want to define the behavior as usually, pq_terminate_backend() will kill a backend that's blocked on sending to the client, but sometimes you have to call it twice (or more!) to really kill it. I agree that it is desirable

Re: [HACKERS] Escaping from blocked send() reprised.

2014-08-26 Thread Kyotaro HORIGUCHI
Hello, I condiered it but select() frequently (rather in most cases when send() blocks by send buffer exhaustion) fails to predict that following send() will be blocked. (If my memory is correct.) So the final problem would be blocked send()... My point was to put the socket in

Re: [HACKERS] Escaping from blocked send() reprised.

2014-08-25 Thread Heikki Linnakangas
On 07/01/2014 06:26 AM, Kyotaro HORIGUCHI wrote: At Mon, 30 Jun 2014 11:27:47 -0400, Robert Haas robertmh...@gmail.com wrote in CA+TgmoZfcGzAEmtbyoCe6VdHnq085x+ox752zuJ2AKN=wc8...@mail.gmail.com 1. I think it's the case that there are platforms around where a signal won't cause send() to

Re: [HACKERS] Escaping from blocked send() reprised.

2014-07-04 Thread Kyotaro HORIGUCHI
Hello, At Tue, 1 Jul 2014 21:21:38 +0200, Martijn van Oosterhout klep...@svana.org wrote in 20140701192138.gb20...@svana.org On Tue, Jul 01, 2014 at 12:26:43PM +0900, Kyotaro HORIGUCHI wrote: 1. I think it's the case that there are platforms around where a signal won't cause send() to

Re: [HACKERS] Escaping from blocked send() reprised.

2014-07-04 Thread Kyotaro HORIGUCHI
Hello, thank you for keeping this discussion moving. I think there's no such a reasonable time. The behavior might should be determined from another point.. On alternative would be let pg_terminate_backend() have a parameter instructing force shutodwn (how to propagate it?), or make a

Re: [HACKERS] Escaping from blocked send() reprised.

2014-07-01 Thread Robert Haas
On Mon, Jun 30, 2014 at 11:26 PM, Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp wrote: 2. I think it would be reasonable to try to kill off the connection without notifying the client if we're unable to send the data to the client in a reasonable period of time. But I'm unsure what a

Re: [HACKERS] Escaping from blocked send() reprised.

2014-07-01 Thread Martijn van Oosterhout
On Tue, Jul 01, 2014 at 12:26:43PM +0900, Kyotaro HORIGUCHI wrote: 1. I think it's the case that there are platforms around where a signal won't cause send() to return EINTR and I'd be entirely unsurprised if SSL_write() doesn't necessarily return EINTR in that case. I'm not sure

Re: [HACKERS] Escaping from blocked send() reprised.

2014-06-30 Thread Robert Haas
On Mon, Jun 30, 2014 at 4:13 AM, Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp wrote: Hello, I have received inquiries related to blocked communication several times for these weeks with different symptoms. Then I found this message from archive,

Re: [HACKERS] Escaping from blocked send() reprised.

2014-06-30 Thread Kyotaro HORIGUCHI
Hello, The replies follow are mainly as a memo for myself so please don't be bothered to answer until the time comes. At Mon, 30 Jun 2014 11:27:47 -0400, Robert Haas robertmh...@gmail.com wrote in CA+TgmoZfcGzAEmtbyoCe6VdHnq085x+ox752zuJ2AKN=wc8...@mail.gmail.com You should probably add your