<commit_before>:github_url:

.. _session:

.. index::
	single: zugbruecke.ctypes
	single: zugbruecke.ctypes_session

The Session Model
=================

*zugbruecke* operates based on a session model. Every session represents a separate *Windows* *Python* interpreter process running on *Wine*. *zugbruecke* starts a default session during the import of ``zugbruecke.ctypes``, but the user can start more sessions if required. Sessions are identified by a unique (hash) ID string. Sessions have a life-cycle and require termination routines to run before they can be dropped or deleted. By default, sessions terminate themselves automatically when the *Python* interpreter quits.

The following notable ``ctypes`` methods and classes and their functionality are linked to individual sessions and therefore depend on their internal state: ``cdll``, ``CDLL``, ``CFUNCTYPE``, ``windll``, ``WinDLL``, ``WINFUNCTYPE``, ``oledll``, ``OleDLL``, ``FormatError``, ``get_last_error``, ``GetLastError``, ``set_last_error`` and ``WinError``. In addition, the methods from ``ctypes.util``, i.e. ``find_library`` and ``find_msvcrt``, are also linked to individual sessions.

Working with sessions
---------------------

If you are just importing ``zugbruecke`` with ``import zugbruecke``, no session is started.

The default session is started if you import ``zugbruecke.ctypes`` with ``import zugbruecke.ctypes`` or if you import any sub-modules such as ``util`` with ``import zugbruecke.ctypes.util``. In most use-cases, you will not care about sessions. The default session is usually enough. It will automatically be terminated when the *Unix* *Python* interpreter stops running.

You may choose to run more than one session at a time for more advanced problems. For example, accessing different DLLs might require different session configurations for individual DLLs. Anther use case may be multithreading, where you might want to operate one session per thread.

.. _sessionclass:

Class: ``zugbruecke.ctypes_session``
------------------------------------

By creating an instance of this class, a new session can be started. The number of instances/sessions is only (theoretically) limited by the amount of available memory and by the number of available network ports on the host system (two ports per instance are required). The :ref:`constructor can be configured <configconstructor>`. The following example illustrates the life cycle of a session object:

.. code:: python<commit_msg>session autoclass<commit_after>:github_url:

.. _session:

.. index::
	single: zugbruecke.ctypes
	single: zugbruecke.ctypes_session

The Session Model
=================

*zugbruecke* operates based on a session model. Every session represents a separate *Windows* *Python* interpreter process running on *Wine*. *zugbruecke* starts a default session during the import of ``zugbruecke.ctypes``, but the user can start more sessions if required. Sessions are identified by a unique (hash) ID string. Sessions have a life-cycle and require termination routines to run before they can be dropped or deleted. By default, sessions terminate themselves automatically when the *Python* interpreter quits.

The following notable ``ctypes`` methods and classes and their functionality are linked to individual sessions and therefore depend on their internal state: ``cdll``, ``CDLL``, ``CFUNCTYPE``, ``windll``, ``WinDLL``, ``WINFUNCTYPE``, ``oledll``, ``OleDLL``, ``FormatError``, ``get_last_error``, ``GetLastError``, ``set_last_error`` and ``WinError``. In addition, the methods from ``ctypes.util``, i.e. ``find_library`` and ``find_msvcrt``, are also linked to individual sessions.

Working with sessions
---------------------

If you are just importing ``zugbruecke`` with ``import zugbruecke``, no session is started.

The default session is started if you import ``zugbruecke.ctypes`` with ``import zugbruecke.ctypes`` or if you import any sub-modules such as ``util`` with ``import zugbruecke.ctypes.util``. In most use-cases, you will not care about sessions. The default session is usually enough. It will automatically be terminated when the *Unix* *Python* interpreter stops running.

You may choose to run more than one session at a time for more advanced problems. For example, accessing different DLLs might require different session configurations for individual DLLs. Anther use case may be multithreading, where you might want to operate one session per thread.

.. _sessionclass:

Class: ``zugbruecke.CtypesSession``
------------------------------------



.. autoclass:: zugbruecke.CtypesSession
    :members:



By creating an instance of this class, a new session can be started. The number of instances/sessions is only (theoretically) limited by the amount of available memory and by the number of available network ports on the host system (two ports per instance are required). The :ref:`constructor can be configured <configconstructor>`. The following example illustrates the life cycle of a session object:

.. code:: python
{'fraction_non_alphanumeric': 0.11321130123358536, 'fraction_numerical': 0.0, 'mean_word_length': 4.648314606741573, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 5, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3168597', 'n_tokens_mistral': 1320, 'n_tokens_neox': 1282, 'n_words': 635}