Op 2010-06-22 14:13, Michael Schnell het geskryf: > The "Linux Way" is more like doing separate executable than doing > threads, as Linux always provided high-performance inter process > communication (e.g. pipes, usable with "select()" etc.) and process > starting ( "fork()" ).
Form the previous links I posted, Linux had kernel level threading support since 1.3.56 - that is ages ago. This is very different to the old "creating new processes" idea. "As of 1.3.56, Linux has supported kernel-level multithreading." -- http://linas.org/linux/threads-faq.html > Of course you can avoid using the library, do the stuff in Pascal and > directly access the Kernel API, but this might be dangerous in case the > API might be modified some time in the future Wouldn't the same apply to the pthreads library? From what I understand the currently implementation of NTPL is very good, so I doubt it will change any time soon. > or if it's different with > different archs (e.g. some archs don't provide FUTEX). Start with one platform and implement others as you go on, if they support kernel level threading API. Otherwise fall back to glibc as is currently done. This should minimize dependencies on platforms that support it. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
