How to handle the new NUMA_NODE_RELATIONSHIP structure

[Daniel Widdis]

I started to update the NUMA_NODE_RELATIONSHIP structure as mentioned in https://github.com/java-native-access/jna/issues/1324

 

The docs have been updated at https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-numa_node_relationship to show what is available in Windows Insider headers and will be in a future release.

 

The use of the last two bytes of “Reserved” isn’t a problem; simply adding a field.  However, the singular field GROUP_AFFINITY GroupMask is now an array: GROUP_AFFINITY[] GroupMasks.   (Technically it’s a union with one or the other.)

 

Handling it in a new structure is easy; we initialize it with size 1 which has the space for the existing GroupMask.  However, any users relying on that would need to update their code to now refer to GroupMasks[0].

 

Implementing the union as the API has it doesn’t really provide added value for the variable size array and still breaks compatibility on the Java side.

 

The only non-API-breaking way to handle it that I can think of is to leave the GroupMask field and potentially add another array field after this; however, this would possibly be zero-sized which doesn’t work well either.

 

I’m leaning toward the non-backwards-compatible route, with a note in the change log.  Any better ideas?

 

 

[Daniel Widdis]

Just thought of a possible solution.  Include both fields and override getFieldList() and getFieldOrder() to remove the one not used.  We’d still need to do some sort of test on the build number to switch between them.

[Matthias Bläsing]

Hi,

what would you think about this idea (I assume the structure is read-
only):

Let JNA handle only nodeNumber, reserved, groupCount and _groupMasks_.
As you suggest in the PR. In read() check the groupCount - if it is 0,
override that to 1. I assume, that at least one structure must be there
(the old case). After the call to super.read, set the value of
groupMask to groupMasks[0].

Would that make sense?

Greetings

Matthias

> --
> You received this message because you are subscribed to the Google
> Groups "Java Native Access" group.
> To unsubscribe from this group and stop receiving emails from it,
> send
> an email to jna-users+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jna-users/E79CC79C-A222-4F95-8467-D9C3EF4A6F17%40gmail.com
> .

[Daniel Widdis]

> check the groupCount - if it is 0, override that to 1.

I'd prefer to leave this as 0 so the user has information to detect the difference if they choose to do so. We can assume 1 internally.

> After the call to super.read, set the value of groupMask to groupMasks[0].

This is a very elegant solution. We keep the older member there and populate it appropriately for backwards compatibility, but ignore it from a JNA structure/field-reading point of view.

I think this still requires overriding getFieldList/getFieldOrder but it avoids the conditionals. I'll update the PR with this approach.

To view this discussion on the web visit https://groups.google.com/d/msgid/jna-users/ad47f01a6500cb440b6a24eb164ddee50370e4a4.camel%40doppel-helix.eu.