When changing select() calls for delays into pg_usleep(), two comments

bmomjian · bmomjian · commit 48b2802eeeaa · 2004-03-23T21:39:46.000Z
in s_lock.c were not updated, and still refers to select. Made my grep
hit the wrong files, so I figured a simple patch was in order.. (other
refs in the same comment block was changed..)

Magnus Hagander
diff --git a/src/backend/storage/lmgr/s_lock.c b/src/backend/storage/lmgr/s_lock.c
@@ -9,7 +9,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/storage/lmgr/s_lock.c,v 1.26 2004/03/15 16:18:43 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/storage/lmgr/s_lock.c,v 1.27 2004/03/23 21:39:46 momjian Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -45,15 +45,15 @@ void
 s_lock(volatile slock_t *lock, const char *file, int line)
 {
 	/*
-	 * We loop tightly for awhile, then delay using select() and try
+	 * We loop tightly for awhile, then delay using pg_usleep() and try
 	 * again. Preferably, "awhile" should be a small multiple of the
 	 * maximum time we expect a spinlock to be held.  100 iterations seems
 	 * about right.  In most multi-CPU scenarios, the spinlock is probably
 	 * held by a process on another CPU and will be released before we
 	 * finish 100 iterations.  However, on a uniprocessor, the tight loop
 	 * is just a waste of cycles, so don't iterate thousands of times.
 	 *
-	 * Once we do decide to block, we use randomly increasing select()
+	 * Once we do decide to block, we use randomly increasing pg_usleep()
 	 * delays. The first delay is 10 msec, then the delay randomly
 	 * increases to about one second, after which we reset to 10 msec and
 	 * start again.  The idea here is that in the presence of heavy

Original file line number	Diff line number	Diff line change
`@@ -9,7 +9,7 @@`
`9`	`9`	`*`
`10`	`10`	`*`
`11`	`11`	`* IDENTIFICATION`
`12`		`- * $PostgreSQL: pgsql/src/backend/storage/lmgr/s_lock.c,v 1.26 2004/03/15 16:18:43 momjian Exp $`
	`12`	`+ * $PostgreSQL: pgsql/src/backend/storage/lmgr/s_lock.c,v 1.27 2004/03/23 21:39:46 momjian Exp $`
`13`	`13`	`*`
`14`	`14`	`*-------------------------------------------------------------------------`
`15`	`15`	`*/`
`@@ -45,15 +45,15 @@ void`
`45`	`45`	`s_lock(volatile slock_t lock, const char file, int line)`
`46`	`46`	`{`
`47`	`47`	`/*`
`48`		`- * We loop tightly for awhile, then delay using select() and try`
	`48`	`+ * We loop tightly for awhile, then delay using pg_usleep() and try`
`49`	`49`	`* again. Preferably, "awhile" should be a small multiple of the`
`50`	`50`	`* maximum time we expect a spinlock to be held. 100 iterations seems`
`51`	`51`	`* about right. In most multi-CPU scenarios, the spinlock is probably`
`52`	`52`	`* held by a process on another CPU and will be released before we`
`53`	`53`	`* finish 100 iterations. However, on a uniprocessor, the tight loop`
`54`	`54`	`* is just a waste of cycles, so don't iterate thousands of times.`
`55`	`55`	`*`
`56`		`- * Once we do decide to block, we use randomly increasing select()`
	`56`	`+ * Once we do decide to block, we use randomly increasing pg_usleep()`
`57`	`57`	`* delays. The first delay is 10 msec, then the delay randomly`
`58`	`58`	`* increases to about one second, after which we reset to 10 msec and`
`59`	`59`	`* start again. The idea here is that in the presence of heavy`