Re: mt-safe ESQL/C programming

Kenneth Xu wrote: > No, I don't agree! Using thread at least have two advantages, first threads > are not as costly as a process to OS, Communication between treads are much > easier and fast then processes. > Although, even each child do independent DB operation, they may need to > share their variables or want to sync in certain point. > > Michael Segel wrote in message > > >Why not avoid any potential problem by using fork() instead of > >threads?If each child is going to maintain its own independant DB > >connection, does > >threads make sense? Or is it just fashionable? Sigh. You can't have your cake and eat it too. (Well unless you use a thread safe library....) Yes, I realize that there is overhead in forked processes versus threads. But you can eliviate that issue through other means. You can share and sync between forked processes via shared memory or IPC. You have to judge the overhead issues. (Cost vs Benifits) The question, is how tight are the threads. Of course, a funny thing to consider. Forks may have less costs in an smp environment than threads. For example, what happens when a parent thread is on one CPU, and the child thread is on another at the same time? (Deadlock? :-) ) Anyways, it was just a sugestion, and you got what you paid for it. -Mikey