Difference between pages "r7.1.1:Define LIBSHARED PAL THREAD CALLING CONVENTION" and "r7.1.1:Define LIBSHARED PAL THREAD RETURN TYPE"

From liblfds.org
(Difference between pages)
Jump to navigation Jump to search
m (1 revision imported)
 
m (1 revision imported)
 
Line 1: Line 1:
{{DISPLAYTITLE:define LIBSHARED_PAL_THREAD_CALLING_CONVENTION}}
{{DISPLAYTITLE:define LIBSHARED_PAL_THREAD_RETURN_TYPE}}
==Source File==
==Source File==
  └───test_and_benchmark
  └───test_and_benchmark
Line 8: Line 8:


==Define==
==Define==
  #define LIBSHARED_PAL_THREAD_CALLING_CONVENTION [calling convention]
  #define LIBSHARED_PAL_THREAD_RETURN_TYPE libshared_pal_thread_return_t
or
#define LIBSHARED_PAL_THREAD_RETURN_TYPE  int


==Example==
==Example==
  #define LIBSHARED_PAL_THREAD_CALLING_CONVENTION WINAPI
  #define LIBSHARED_PAL_THREAD_RETURN_TYPE libshared_pal_thread_return_t


==Optionality==
==Optionality==
This define is mandatory and the library cannot compile if in the cases where it is needed, it is not set.
This define is mandatory and the library cannot compile if it is not set.


==Notes==
==Notes==
Windows specifies a particular calling convention for thread functions.  This define masks that convention across platforms, by being set but empty on other platforms.
Windows kernel mode threads are unique in that the thread function returns ''void''.  As such, two problems are presented; firstly, the existing code, which is cross-platform and so has thread functions which return a variable, often attempts to declare on the stack a variable of the type ''libshared_pal_thread_return_t'', which is set to a value during the course of operation and then returned.  However, if ''libshared_pal_thread_return_t'' is ''void'', then the compiler throws an error, because it is not possible to declare variables of type ''void''.  Secondly, the return from the thread function must be empty - where all the existing threads are returning a value or variable.
 
To solve this, one define (this define) and one macro (''[[r7.1.1:macro LIBSHARED_PAL_THREAD_RETURN_CAST|LIBSHARED_PAL_THREAD_RETURN_CAST]]'') are provided.  This define provides for Windows kernel a harmless type which will permit the thread function code to compile.  The macro ''LIBSHARED_PAL_THREAD_RETURN_CAST'' wraps the return argument and on Windows kernel, consumes it - makes it disappear - by being an empty macro.  On other platforms, the macro itself disappears, leaving just its argument, which then gives us what we want in both cases.


==See Also==
==See Also==
* [[r7.1.1:Porting Guide (libshared)|Porting Guide (libshared)]]
* [[r7.1.1:Porting Guide (libshared)|Porting Guide (libshared)]]

Latest revision as of 20:16, 17 February 2017

Source File

└───test_and_benchmark
    └───libshared
        └───inc
            └───libshared
                    libshared_porting_abstraction_layer_compiler.h

Define

#define LIBSHARED_PAL_THREAD_RETURN_TYPE  libshared_pal_thread_return_t

or

#define LIBSHARED_PAL_THREAD_RETURN_TYPE  int

Example

#define LIBSHARED_PAL_THREAD_RETURN_TYPE  libshared_pal_thread_return_t

Optionality

This define is mandatory and the library cannot compile if it is not set.

Notes

Windows kernel mode threads are unique in that the thread function returns void. As such, two problems are presented; firstly, the existing code, which is cross-platform and so has thread functions which return a variable, often attempts to declare on the stack a variable of the type libshared_pal_thread_return_t, which is set to a value during the course of operation and then returned. However, if libshared_pal_thread_return_t is void, then the compiler throws an error, because it is not possible to declare variables of type void. Secondly, the return from the thread function must be empty - where all the existing threads are returning a value or variable.

To solve this, one define (this define) and one macro (LIBSHARED_PAL_THREAD_RETURN_CAST) are provided. This define provides for Windows kernel a harmless type which will permit the thread function code to compile. The macro LIBSHARED_PAL_THREAD_RETURN_CAST wraps the return argument and on Windows kernel, consumes it - makes it disappear - by being an empty macro. On other platforms, the macro itself disappears, leaving just its argument, which then gives us what we want in both cases.

See Also