Re: [HACKERS] socket calls in signal handler (WAS:
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] socket calls in signal handler (WAS: |
Дата | |
Msg-id | 200403171320.i2HDKdX22253@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] socket calls in signal handler (WAS: APC + socket r (Claudio Natoli <claudio.natoli@memetrics.com>) |
Список | pgsql-hackers-win32 |
Magnus is still researching the APC issue. I am talking to him regularly on this item. --------------------------------------------------------------------------- Claudio Natoli wrote: > > [reviving this at great personal risk on win32] > > > Claudio Natoli wrote: > > > The specific (and possibly only? are their others?) issue is the call to > > > pgstat_beterm from reaper/CleanupProc, invoked by a SIGCHLD. Can this > call > > > be deferred to the main loop (ie. ServerLoop) and is there any merit in > > > doing so? > > > > Just canvassing for options. If we can get a win32 specific > > change that we trust, great! (I think it goes without saying > > that, throughout the work on this port, we've tried to avoid > > changing the existing code as much as possible). However, if > > we can not, I'd like to have other options, and am exploring > > this possibility. > > How are we going to work around this issue? > > ISTM we have four options: > (a) Finding out for sure whether or not socket calls within APCs mash the > state of the internal socket libs etc. We (now) know that a socket call > within an APC will cause a currently blocked socket call to fail without > error, but is anything else hammered that we don't (yet) know about? If we > can determine that the answer is no, we have a simple work-around (ie. > setting a flag like APCcalled, and checking on return from select...) > (b) Another win32 work-around (like pushing the pgstat_send call out on a > separate thread, if allowed) > (c) Deferring the pgstat_beterm call > and, ah: > (d) Rewriting the win32 signal code > > Ok. So we really have (at most) three options :-) > > Is (c) out of the question? And, regardless of the answer to this, does > anyone have a definitive answer to (a), or what might be allowed in (b)? > > Cheers, > Claudio > > > > --- > Certain disclaimers and policies apply to all email sent from Memetrics. > For the full text of these disclaimers and policies see > <a > href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em > ailpolicy.html</a> > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-hackers-win32 по дате отправления: