XPost: alt.os.development   
   From: maxim@storagecraft.com   
      
   > > Why not use functions for threads, rendezvous and mutexes? Why bother the   
   > > language itself with such?   
   >   
   > Firstly, it is too low-level. Secondly, functional decomposition does not   
   > well capture the semantics of concurrency. Thirdly, OSes always were better   
   > than that.   
      
   Disadvantages: lack of flexibility, hiding of subtle details, complete "black   
   box" known to the compiler vendor only, unportable (the underlying mechanics   
   cannot be easily ported since this is a trade secret of the compiler vendor,   
   remember the story of RtlUnwind call in Windows?), cannot be extended and/or   
   updated, major issues in creating a debugger, and so on.   
      
   Functional decompositin matches the semantics of concurrency very well. What is   
   wrong in EnterCriticalSection/LeaveCriticalSection calls and CRITICAL_SECTION   
   object?   
      
   Supporting any complex stuff at language level is usually evil. That's why C   
   and C++ is so popular. C++ only does exceptions and RTTI at language level, and   
   is heavily criticized for the latter (#define-based RTTI is better).   
      
   > about safe, distributed, preemptive, portable, scalable, real-time etc   
   > system, I see no way to handle it without addressing these issues on the   
   > language level.   
      
   Linux is safe, distributed, portable, scalable, real-time (with extensions)   
   system, without the thread support at language level. The kernel has no C++ in   
   it IIRC. Pure C.   
      
   --   
   Maxim Shatskih, Windows DDK MVP   
   StorageCraft Corporation   
   maxim@storagecraft.com   
   http://www.storagecraft.com   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)