Klemens Friedl wrote:
2007/8/29, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
I think you will be much much better off to put every
thread it is own private address space. In other words,
turn each thread into a separate process. Threads are
an invention of the devil. Stay as far away from these
fiendish abominations as you can get.
In Unix processes are rather cheap ("fork", etc.), and as threads got
added late (mid 90ies) to the unix (posix) standard, several
concurrent threading implementation are spreading around, and pthread
is just one of them. Famous book "Advanced Programming in Unix
Environment" by Stevens (1992) doesn't cover threads at all, but
processes. Butenhof's "Programming with POSIX Threads" (1997) is one
of the first and best book that explains the new standard unix
threads.
In Win32, process are more expensive (more management overhead), and
threads, "fibers" or even "I/O complettion ports" are the prefered way
to go.
Well, I'm already using boost::thread for this application on win32.
Since the application will not be finished before sqlite 3.5 I just
though I could develop using 3.5 and help finding sqlites
multithread-bugs at the same time. This is why I originally asked the
question about the best practice when going multithread on SQLite 3.5.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
