Date: Tue, 22 Jun 2021 13:16:26 +0000
> Am Montag, den 21.06.2021, 19:49 +0000 schrieb Billy O'Neal (VC LIBS):
> > (2 different DLLs which link different CRTs have no means to
> > coordinate on where the lock table lives)
>
> Out of curiosity: Why is this so? In principe, this does not sound imossible...
>
> And does this imply that other state in the standard library is then also not
> shared between different parts of a program?
Windows uses a different distribution model than Linux and Mac. The C-runtime that most users use is not an OS component. In addition, users can bundle an independent copy of the C-runtime with their application, through either static linking, or by bundling the DLLs in the same application directory.
All the C-runtimes could maybe depend on yet another DLL to host the lock table (I think atomic-ref does this?), but then you need to communicate to customers that they can't deploy applications using this variety of atomics unless they distribute the extra DLLs, and put it in system locations. Or you let the current distribution mechanism stand, and atomic refs that cross C-runtime "islands" aren't synchronized with each other, because each is using a different lock table.
And yes, this same argument applies to other global state in the standard library, though the solution space for each can be a little different.
> > (2 different DLLs which link different CRTs have no means to
> > coordinate on where the lock table lives)
>
> Out of curiosity: Why is this so? In principe, this does not sound imossible...
>
> And does this imply that other state in the standard library is then also not
> shared between different parts of a program?
Windows uses a different distribution model than Linux and Mac. The C-runtime that most users use is not an OS component. In addition, users can bundle an independent copy of the C-runtime with their application, through either static linking, or by bundling the DLLs in the same application directory.
All the C-runtimes could maybe depend on yet another DLL to host the lock table (I think atomic-ref does this?), but then you need to communicate to customers that they can't deploy applications using this variety of atomics unless they distribute the extra DLLs, and put it in system locations. Or you let the current distribution mechanism stand, and atomic refs that cross C-runtime "islands" aren't synchronized with each other, because each is using a different lock table.
And yes, this same argument applies to other global state in the standard library, though the solution space for each can be a little different.
Received on 2021-06-22 08:16:31