win32 signals, part 4
Ok, here we go again.
Taking into account Claudios comments on the previous patch, as well as
some more fooling around here of my own, here's a fourth (and final?)
one.
If there are no further comments from Claudio or anyone else, I feel
this is now ready to be applied.
Differences from last version:
1) Per Claudios suggestion, create a "babysitter thread" for each
process that waits on the process and signals ourselves. This reduces
the amount of code (=good) and most importantly removes all the
synchronisation issues (=even better). The only thing left to sync is
the signal delivery, and that has alreay been taken care of in previous
patches.
2) Make pg_queue_signal() no longer be static. This way we don't have to
go through named pipes when signalling ourselves.
3) Remove the redefinition of select() again. This also means that the
select.c file previously incouded should *NOT* be included any more. See
separate mail to hackers-win32 on this issue.
4) Fix Claudios wrong-assignment error in win32_removeChild. Also
improve an error message in win32_waitpid.
Again, the preivously attached select.c file should *NOT* be included.
//Magnus
Ok, so apparantly I was supposed to attach a file there.
//Magnus
Show quoted text
-----Original Message-----
From: Magnus Hagander
Sent: den 4 februari 2004 23:09
To: pgsql-patches@postgresql.org
Cc: pgsql-hackers-win32; Claudio Natoli
Subject: [pgsql-hackers-win32] win32 signals, part 4Ok, here we go again.
Taking into account Claudios comments on the previous patch, as well as
some more fooling around here of my own, here's a fourth (and final?)
one.If there are no further comments from Claudio or anyone else, I feel
this is now ready to be applied.Differences from last version:
1) Per Claudios suggestion, create a "babysitter thread" for each
process that waits on the process and signals ourselves. This reduces
the amount of code (=good) and most importantly removes all the
synchronisation issues (=even better). The only thing left to sync is
the signal delivery, and that has alreay been taken care of in previous
patches.2) Make pg_queue_signal() no longer be static. This way we
don't have to
go through named pipes when signalling ourselves.3) Remove the redefinition of select() again. This also means that the
select.c file previously incouded should *NOT* be included any
more. See
separate mail to hackers-win32 on this issue.4) Fix Claudios wrong-assignment error in win32_removeChild. Also
improve an error message in win32_waitpid.Again, the preivously attached select.c file should *NOT* be included.
//Magnus
---------------------------(end of
broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to
majordomo@postgresql.org
Attachments:
win32_signals_4.patchapplication/octet-stream; name=win32_signals_4.patchDownload+214-187
Import Notes
Resolved by subject fallback
If there are no further comments from Claudio or anyone else, I feel
this is now ready to be applied.
Code walkthrough looks good.
One final minor point to discuss:
Is being unable to set a handler for things like CTRL_C_EVENT,
CTRL_SHUTDOWN_EVENT etc really a non-fatal error? ISTM that, if we can't
guarantee to cleanly handle externally generated signals (like a shutdown
request) or those that could occur internally (like, say, SIGFPE, which I'm
guessing you'll get to), then we probably ought to bail.
Either way, I agree that we ought to get this patch in as is.
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>Import Notes
Resolved by subject fallback
Magnus Hagander wrote:
Ok, here we go again.
Taking into account Claudios comments on the previous patch, as well as
some more fooling around here of my own, here's a fourth (and final?)
one.If there are no further comments from Claudio or anyone else, I feel
this is now ready to be applied.Differences from last version:
1) Per Claudios suggestion, create a "babysitter thread" for each
process that waits on the process and signals ourselves. This reduces
the amount of code (=good) and most importantly removes all the
synchronisation issues (=even better). The only thing left to sync is
the signal delivery, and that has alreay been taken care of in previous
patches.
IIRC a separate "babysitter thread" just to handle message passing is
exactly what Katie Ward did for UltraSQL ... the Win32 port done at
NuSphere. Glad to see she was right about that.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
IIRC a separate "babysitter thread" just to handle message passing is
exactly what Katie Ward did for UltraSQL ... the Win32 port done at
NuSphere. Glad to see she was right about that.
Or Katie and I are both "wrong" :-P
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>Import Notes
Resolved by subject fallback
"Magnus Hagander" <mha@sollentuna.net> writes:
Taking into account Claudios comments on the previous patch, as well as
some more fooling around here of my own, here's a fourth (and final?)
one.
I'll apply this tonight barring any objections.
-Neil
Taking into account Claudios comments on the previous patch,
as well as
some more fooling around here of my own, here's a fourth (and final?)
one.
Actually, please hold just a second :-)
I have an updated version of this patch that fixes the remaining small
issue (FATAL on failure to set the control handler). Will post later
tonight or early tomorrow. Only veyr small changes, so if there are no
objections to this one, there shouldn't be to that one either.
Thanks,
Magnus
Import Notes
Resolved by subject fallback