rtl/objpas/classes/classes.inc:
+ new variable ExternalThreadsCleanup to keep track whether ExternalThreads list is currently cleared
* TExternalThread.Create: add the thread instance to the external thread list
* TExetrnalThread.Destroy: remove the thread instance from the external thread list (if not in system cleanup anyway)
* CommonCleanup: set ExternalThreadsCleanup to true so that the threads don't remove themselves from the list anymore
+ added test
git-svn-id: trunk@31028 -
Each port that allows the usage of dynamic libraries should call InitSystemDynLibs during initialization of the System unit.
The DynLibs unit has been adjusted to be a forwarder for the functions that now reside in the System unit (for backwards compatiblity just in case). Additionally the unit will register the DynLibsManager if it doesn't reside in the System unit anyway.
Currently only the Windows targets (Win32, Win64 and WinCE) implement the DynLibsManager inside the System unit. For other systems using the LoadLibrary, etc. functions will lead to a run error/exception.
If a port wants to implement its own DynLibsManager then it needs to define DISABLE_NO_DYNLIBS_MANAGER. TLibHandle, NilHandle and optionally TOrdinalEntry (it's set to SizeUInt otherwise) should be defined in sysdlh.inc which needs to be enabled using the define FPC_SYSTEM_HAS_SYSDLH (because there are targets which have FEATURE_DYNLIBS enabled, but don't support them... e.g. powerpc-wii -.-).
The DynLibsManager contains methods for loading a library based on a RawByteString and based on a UnicodeString. BOTH should be implemented, but internally one can forward to the other.
The loading by ordinal *can* be be implemented. If it is set to Nil then the implementation of GetProcAddress(lib,ordinal) will return Nil.
+ new functions SetDynLibsManager and GetDynLibsManager to set and retrieve the current DynLibsManager
* provide interface of DynLibs unit in unit System
git-svn-id: trunk@29613 -
rtl/objpas/types.pp:
+ readd RT_RCDATA as a reference to the one declared in the Windows unit for Win32 and Win64; also add a deprecated message that advices users to use the one declared in the Windows instead.
git-svn-id: trunk@29127 -
functionality with RTLEvent:
o the thread manager semaphore functionality isn't used for anything else,
and the main difference between mutex/condvar and semaphores is that the
latter can be used for IPC (while the thread manager is always used
within a single process) and that they are counting (but since a thread
can only suspend itself nowadays, it cannot be suspended recursively)
o OS X sandboxing does not support the use of semaphores (or rather: Apple
does not allow sandboxing rules that enable the use of IPC semaphores in
the appstore)
git-svn-id: trunk@28965 -
