Subj : Re: A pity that there is no forkall() which clones threads To : comp.programming.threads From : Marcin 'Qrczak' Kowalczyk Date : Sat Mar 05 2005 02:17 pm Giancarlo Niccolai writes: > I suggest you to study the topic before writing the code, and not to > get in love with your code before studying what others have done and > why. I do study others' papers, but I haven't seen much on the subject of interaction of threads with fork. Do you know some papers about this? > Unless you are talking about "lightweight" or "emulated" language > level threading, where you are free to do whatever may seem > consistent as you can control it; but in the rest of your mail you > talk about pthreads, so I suppose that this three functions are not > the case. I mean both. More precisely, I mean threads in my language, which are implemented using a hybrid of lightweight threads and pthreads. Haskell people have developed a really clever design which suits my needs. If I could use forkall, then the semantics of threads at fork would be consistent no matter which threads are inside a background C computation or callback from C (which makes them bound to a separate pthread). With only fork available it's impossible to clone threads running arbitrary C code and thus the semantics gets inconsistent: when a thread reaches a point where running it further would be unimplementable, it must be killed. The semantics is deterministic modulo memory leaks, but ugly and less useful than with forkall. Only ForkProcessKillThreads is truly consistent, but really usable only shortly before exec, or when other threads are not used anyway. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/ .