|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
AlanFord
Joined: 17 May 2005 Posts: 2
|
Posted: Thu May 19, 2005 7:16 pm Post subject: multi-threading compiler options |
|
|
I'm attempting to compile a library with FTN95 that will be
called from an ASP.NET application. Given the odd runtime
errors I've encountered, I believe the library must be compiled
as a multithreaded library.
Can anyone explain the differences between the various
"multithreaded" compiler and linker options that are available
for FTN95 projects in Visual Studio.NET? The three that I've
found are
compiler:
- Use multi-threading (yes/no)
- Use single thread (yes/no)
linker:
- Use multi-threading (yes/no)
Is the "yes, no, yes" combiniation the most appropriate for
multithreaded .NET libraries? Finally, does FTN95 use
the STA or MTA multithreading model?
Thanks in advance,
Alan Ford |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Mon May 23, 2005 3:58 am Post subject: multi-threading compiler options |
|
|
The FTN95 command line switches /MULTI_THREADED and /SINGLE_THREADED are redundant unless /LINK is also used.
SINGLE_THREADED means "not MULTI_THREADED".
SINGLE_THREADED is the default.
The inclusion of these options in Plato and Visual Studio projects is a mistake because both IDEs always use explicit linking.
DBK_LINK has the command line switch /MULTI_THREADED. It assumes, by default, that only a single thread is used.
When /MULTI_THREADED is used, DBK_LINK sets a flag that enables tread-safe processing in ftn95lib.dll.
In particular this is required if calls are made to CREATE_THREAD@ or CREATE_THREAD1@ or if a thread is created directly using
System.Threading.Thread methods. These calls could be in the executable or in a library that it calls.
The only reason for including the MULTI_THREADING option is to reduce system overheads incurred when using multi-threading.
You can leave it switched on without any adverse effect other than to slow things down a little.
I am not sure about the implications for STA's and MTA's but in this respect I guess that FTN95 can be considered
as an interface to the .NET Framework. You can access COM objects from .NET and hence indirectly from FTN95.
Each COM object that is accessed will be designed using either the STA or the MTA model. In either case I doubt that the
MULTI_THREADED switch will make any difference because it mainly influences the way in which ftn95lib.dll behaves.
|
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|