[Python-Dev] SSL support in _socket

[M.-A. Lemburg]

Tim Peters wrote:
> 
> [M.-A. Lemburg]
> > Some explanation:
> >
> > The _ssl module needs access to the type object defined in
> > the _socket module. Since cross-DLL linking introduces a lot of
> > problems on many platforms, the "trick" is to wrap the
> > C API of a module in a struct which then gets exported to
> > other modules via a PyCObject.
> >
> > The code in socketmodule.c defines this struct (which currently
> > only contains the type object reference, but could very
> > well also include other C APIs needed by other modules)
> > and exports it as PyCObject via the module dictionary
> > under the name "CAPI".
> >
> > Other modules can now include the socketmodule.h file
> > which defines the needed C APIs to import and set up
> > a static copy of this struct in the importing module.
> >
> > After initialization, the importing module can then
> > access the C APIs from the _socket module by simply
> > referring to the static struct, e.g.
> >
> >         /* Load _socket module and its C API; this sets up the global
> >            PySocketModule */
> >         if (PySocketModule_ImportModuleAndAPI())
> >                 return;
> >
> >         ...
> >         if (!PyArg_ParseTuple(args, "O!|zz:ssl",
> >
> >                               PySocketModule.Sock_Type,
> >
> >                               (PyObject*)&Sock,
> >                               &key_file, &cert_file))
> >                 return NULL;
> >
> > (Perhaps I should copy the above explanation into the source
> >  files ?!)
> 
> I don't know.  I really don't have time to try and understand this, but I
> can tell you I spent a lot of time staring at the code just trying to fix
> the part that didn't work, and it was slow and painful going.  Without deep
> understanding, I can only repeat that all this machinery *seems* to be
> overkill in this specific case; and since there is no other case in the
> Python core, a mass of overly general machinery in the Python core seems out
> of place.

The idea of using the above framework was to get the 
discussion started and then perhaps extend this kind of 
support to other modules as well, e.g. to be able to
create and access types from other modules at C level.

Note that the framework only seem to be overkill
at the moment (since it only exports one symbol).
As soon as you add more APIs to the API struct,
things look different -- e.g. a socket constructor
at C level would be nice to have.

> > ...
> > Ah, you're right, the export of the type object is not
> > needed anymore since this is now done using the PyCObject.
> > Sorry, my bad.
> 
> No problem -- that part turned out to be easy, once I found it.

You should have just thrown the error message in my Inbox.

> > ...
> > The reason for putting the code in the header file is
> > to avoid duplication of code. The import API is needed by
> > all modules wishing to use the C API of the socket module.
> 
> But in this specific case you confirm that there is only one client:
> 
> > Currently, only _ssl needs this, but I think it would be
> > a good strategy to extend this technique to other modules
> > as well (esp. the array module would be a good candidate).
> 
> Possibly, but it's overly elaborate in this specific case.  If it needed to
> be hypergeneral (and it doesn't here), it seems it would be better to make
> the code template *more* general, so that every importer of every module
> could include a common (e.g.) PyImportModuleAndApi.h header file one or more
> times, after setting a pile of #defines to specialize it to the module at
> hand.

Right.
 
> > I don't think it's overly complicated.
> 
> You've confirmed that it is in this specific case, and that's the only case
> there is in the codebase all the Python developers work with.

Yeah, well, ok :-) You have to get the ball rolling 
somehow ;-) 
 
> > I am curious why the test_socket still fails on Windows
> > though. Both test_socket and test_socket_ssl work just fine on
> > Linux.
> 
> test_socket was a red herring.  Merely trying to import socket died with
> NameError on Windows.  That got fixed too, and the non-SLL socket tests on
> Windows worked fine then.

Thanks.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/