mirror of
https://github.com/SebastianWendel/nixpkgs.git
synced 2024-11-05 17:56:46 +01:00
99f5d2edb4
Currently, the berkeley databases resuses a lot of the same code for the expressions of each version. This consolidates all of the build routines similar to that of the linux kernel. This patch also adds version 6 of BDB.
48 lines
1.6 KiB
Diff
48 lines
1.6 KiB
Diff
diff -rc db-4.5.20-orig/env/env_register.c db-4.5.20/env/env_register.c
|
|
*** db-4.5.20-orig/env/env_register.c 2006-09-09 16:29:04.000000000 +0200
|
|
--- db-4.5.20/env/env_register.c 2007-05-16 21:13:27.000000000 +0200
|
|
***************
|
|
*** 255,260 ****
|
|
--- 255,262 ----
|
|
buf[nr - 1] = '\0';
|
|
}
|
|
|
|
+ //sleep(3);
|
|
+
|
|
pos = (off_t)lcnt * PID_LEN;
|
|
if (REGISTRY_LOCK(dbenv, pos, 1) == 0) {
|
|
if ((ret = REGISTRY_UNLOCK(dbenv, pos)) != 0)
|
|
***************
|
|
*** 361,366 ****
|
|
--- 363,392 ----
|
|
if (recovery_failed)
|
|
goto err;
|
|
|
|
+ //sleep(5);
|
|
+
|
|
+ /*
|
|
+ * Acquire an exclusive lock to prevent a race like this:
|
|
+ *
|
|
+ * 1) Process X is about to exit and process Y is just
|
|
+ * starting.
|
|
+ * 2) Process Y reads X's slot.
|
|
+ * 3) Process X clears its slot.
|
|
+ * 4) Process Y sees that X's slot isn't cleared yet (since it
|
|
+ * just read the old value).
|
|
+ * 5) Process X closes the registry, releases the lock on its
|
|
+ * slot.
|
|
+ * 6) Process Y tries to acquire X's slot and succeeds, so it
|
|
+ * concludes that X died and recovery is needed.
|
|
+ *
|
|
+ * A more efficient solution to this problem would be to let
|
|
+ * __envreg_add acquire the lock on a slot first, and *then*
|
|
+ * read the slot (instead of the other way around). Then we
|
|
+ * wouldn't need the exclusive lock here.
|
|
+ */
|
|
+ if ((ret = REGISTRY_EXCL_LOCK(dbenv, 0)) != 0)
|
|
+ goto err;
|
|
+
|
|
/*
|
|
* Why isn't an exclusive lock necessary to discard a DB_ENV handle?
|
|
*
|