* ipc/ipc_kmsg.c: Remove register qualifiers.
---
ipc/ipc_kmsg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ipc/ipc_kmsg.c b/ipc/ipc_kmsg.c
index 3ad274d..3bdd6b0 100644
--- a/ipc/ipc_kmsg.c
+++ b/ipc/ipc_kmsg.c
@@ -2280,7 +2280,7 @@ ipc_kmsg_copyout_object(space, obj
* ipc/mach_msg.c: Remove register qualifiers.
---
ipc/mach_msg.c | 82 +-
1 file changed, 41 insertions(+), 41 deletions(-)
diff --git a/ipc/mach_msg.c b/ipc/mach_msg.c
index 00ab085..b83738b 100644
--- a/ipc/mach_msg.c
+++ b/ipc/mach_msg.c
* ipc/ipc_pset.c: Trivial stylistic fix for consistency.
---
ipc/ipc_pset.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ipc/ipc_pset.c b/ipc/ipc_pset.c
index c016d27..29f781e 100644
--- a/ipc/ipc_pset.c
+++ b/ipc/ipc_pset.c
@@ -345,7 +345,7 @@ ipc_pset_print(
iprin
* ipc/ipc_table.c: Qualify constants with const.
---
ipc/ipc_table.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ipc/ipc_table.c b/ipc/ipc_table.c
index cbb6a89..78a82f2 100644
--- a/ipc/ipc_table.c
+++ b/ipc/ipc_table.c
@@ -52,10 +52,10 @@ void ipc_table_fill(
* ipc/ipc_thread.h: Remove register qualifiers.
---
ipc/ipc_thread.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/ipc/ipc_thread.h b/ipc/ipc_thread.h
index fbeea46..008ab4a 100644
--- a/ipc/ipc_thread.h
+++ b/ipc/ipc_thread.h
@@ -75,7 +75,7 @@ MACRO_END
#define
Applied, thanks!
Samuel
ports_manage_port_operations_multithread uses two values, totalthreads
and nreqthreads, to manage the threads it creates.
Previously the two values were stored in two variables and a lock was
used to synchronize the access to them.
Use a single variable thread_counts to hold both values. This way
Hi :)
> > > It might be a good idea use atomic operations instead of the spin lock
> > > (which is what the spin lock is using behind the scenes anyways).
> >
> > It may not be possible: further down there is a decision taken depending
> > on totalthreads/nreqthreads becoming 1, and thus you need
Yes, this is what I was thinking of.
I recall there being type defs for appropriate atomic types. If that
is still the recommended approach, please update your patch
appropriately.
The most important thing, however, is ensuring that the semantics are
preserved. That is, was the use of the value