Re: [Sbcl-devel] [Sbcl-commits] master: Rename mutex to lispmutex to avoid OpenIndiana conflict

[Stas Boukarev]

Would "sb_" be more in line with the other names?

On Tue, Oct 31, 2023 at 5:38 PM snuglas via Sbcl-commits <sbcl-c...@lists.sourceforge.net> wrote:

The branch "master" has been updated in SBCL:
       via  8fc35f2c2a3d794bc90556b85fa7eb0fa6b220e9 (commit)
      from  bbe3b9f8b6551916c150c6f63a25b8b199f8274f (commit)

- Log -----------------------------------------------------------------
commit 8fc35f2c2a3d794bc90556b85fa7eb0fa6b220e9
Author: Douglas Katzman <do...@google.com>
Date:   Tue Oct 31 10:34:28 2023 -0400

    Rename mutex to lispmutex to avoid OpenIndiana conflict

    reported by Andreas Wacknitz on sbcl-devel.
---
 src/compiler/generic/genesis.lisp | 2 +-
 src/runtime/backtrace.c           | 2 +-
 src/runtime/linux-os.c            | 8 ++++----
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/compiler/generic/genesis.lisp b/src/compiler/generic/genesis.lisp
index 2b9b82021..ed0bb4e25 100644
--- a/src/compiler/generic/genesis.lisp
+++ b/src/compiler/generic/genesis.lisp
@@ -3373,7 +3373,7 @@ lispobj symbol_package(struct symbol*);~%" (genesis-header-prefix))
   (write-structure-object (layout-info (find-layout 'sb-thread::thread))
                           *standard-output* "thread_instance" nil)
   (write-structure-object (layout-info (find-layout 'sb-thread::mutex))
-                          *standard-output* "mutex" nil)
+                          *standard-output* "lispmutex" nil)
   ;; The os_thread field is either pthread_t or lispobj.
   ;; If no threads, then it's lispobj. #+win32 uses lispobj too
   ;; but it gets cast to HANDLE upon use.
diff --git a/src/runtime/backtrace.c b/src/runtime/backtrace.c
index 747d0cb3e..9c0fd82fa 100644
--- a/src/runtime/backtrace.c
+++ b/src/runtime/backtrace.c
@@ -721,7 +721,7 @@ void libunwind_backtrace(struct thread *th, os_context_t *context)
             // and a mutex have a name at the same slot offset (if #+sb-futex).
             // So to reiterate the comment from linux-os.c -
             // "Use this only if you know what you're doing"
-            struct mutex* lispmutex = (void*)native_pointer(lispthread->waiting_for);
+            struct lispmutex* lispmutex = (void*)native_pointer(lispthread->waiting_for);
             if (lispmutex->name != NIL) {
                 fprintf(stderr, " (MUTEX:\"");
                 print_string(VECTOR(lispmutex->name), stderr);
diff --git a/src/runtime/linux-os.c b/src/runtime/linux-os.c
index 20a69883d..25b0c3fa7 100644
--- a/src/runtime/linux-os.c
+++ b/src/runtime/linux-os.c
@@ -125,7 +125,7 @@ void lisp_mutex_done_eventrecording() {
         rel_time.tv_sec -= basetime.tv_sec;
         rel_time.tv_nsec -= basetime.tv_nsec;
         if (rel_time.tv_nsec<0) rel_time.tv_nsec += 1000 * 1000 * 1000, rel_time.tv_sec--;
-        lispobj threadname = ti->name;
+        lispobj threadname = ti->_name;
         if (events[i].timeout >= 0) // must also have mutex_name in this case
             fprintf(stderr, "[%d.%09ld] %s: %s '%s' timeout %ld\n",
                     (int)rel_time.tv_sec, rel_time.tv_nsec,
@@ -216,8 +216,8 @@ futex_wait(int *lock_word, int oldval, long sec, unsigned long usec)
   int t;

 #ifdef MUTEX_EVENTRECORDING
-    struct mutex* m = (void*)((char*)lock_word - offsetof(struct mutex,state));
-    char *name = m->name != NIL ? vector_sap((m->name) : "(unnamed)";
+    struct lispmutex* m = (void*)((char*)lock_word - offsetof(struct lispmutex,uw_state));
+    char *name = m->name != NIL ? vector_sap(m->name) : "(unnamed)";
 #endif
   if (sec<0) {
       lisp_mutex_event1("start futex wait", name);
@@ -245,7 +245,7 @@ int
 futex_wake(int *lock_word, int n)
 {
 #ifdef MUTEX_EVENTRECORDING
-    struct mutex* m = (void*)((char*)lock_word - offsetof(struct mutex,state));
+    struct lispmutex* m = (void*)((char*)lock_word - offsetof(struct lispmutex,uw_state));
     char *name = m->name != NIL ? vector_sap(m->name) : "(unnamed)";
     lisp_mutex_event1("waking futex", name);
 #endif

-----------------------------------------------------------------------


hooks/post-receive
--
SBCL


_______________________________________________
Sbcl-commits mailing list
Sbcl-c...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-commits

[Douglas Katzman via Sbcl-devel]

Our structure type names are more free-form, I didn't see any consistent use of sb_ on them. 

speaking of conflicts: we really need to stop defining emulations of constants in pthreads_win32.h because that's exactly where I would expect problems.

[Stas Boukarev]

I guess they are not consistent because they usually don't conflict with anything.