ob_type in shared memory

[Mark Wooding]

Aaron Brady <castironpi at gmail.com> writes:

> I am writing an extension using shared memory.  I need a data type
> that is able to reassign its 'ob_type' field depending on what process
> is calling it.

That sounds scary!

> Object 'A' is of type 'Ta'.  When process 'P' is looking at it, it
> needs to have an 'ob_type' that is 'Ta' as process 'P' sees it.  When
> process 'Q' is looking at it, it needs to have an 'ob_type' that is
> 'Ta' as process 'Q' sees it.  If it referred to 'Ta' in process 'P'
> when 'Q' was calling it, 'Q' would have to access memory that is in
> another process.

I see.  My immediate reaction was to suggest that you just put the
PyTypeObject in shared memory -- but then I realised that the shared
memory region will probably be in different addresses in the two
processes.  I'll assume that you've got enough synchronization between
the processes involved to stop everything from turning to mush.

> Therefore, I need a field and an array.  The field indicates which
> type should be loaded, and the array contains the types.  Quick
> example:
>
> PyTypeObject* array_of_types[]= { &SharedList, &SharedTuple };
>
> Then, when a list is being accessed, it can set its own 'ob_type'
> field to 'array_of_types[ 0 ]', and similarly for a tuple.
>
> However, I'm having trouble getting 'array_of_types' in the right
> module during compilation.  My question is: Where do 'array_of_types'
> and the forward declarations for the types go?

I'm not sure I understand the difficulty.  They'll want to go in your C
module somewhere, but as long as SharedList and SharedTuple are either
in the same source file or not declared `static' you just write the
definition you've got somewhere after declaring or defining the actual
types in question.

There's a comment in Extending and Embedding (2.1) about initializing
PyTypeObjects:

:          PyObject_HEAD_INIT(NULL)
: 
: This line is a bit of a wart; what we'd like to write is:
: 
:          PyObject_HEAD_INIT(&PyType_Type)
: 
: as the type of a type object is "type", but this isn't strictly
: conforming C and some compilers complain.

The comment here is wrong: &PyType_Type is a perfectly good constant
expression as far as C is concerned, but alas Microsoft's dynamic
linking system isn't clever enough to cope with it even so (because it's
in a separate link unit).  But this isn't a problem in our case:
presumably SharedList and SharedTuple are in the same module, so this
should all just work.

-- [mdw]