Messages in this thread |  | | Date | Fri, 3 May 1996 12:34:04 +0200 | Subject | Re: clone() and pthreads? | From | (Wolfram Gloger) |
| |
In linux.dev.kernel you write:
>Essentially, the current status of clone() is that the code does work, >and it's used extensively inside the kernel itself, both for kernel >threads and for the normal "fork()" system call. As such, it should be >stable enough to do some real work on.
Well, I have tried, with some success.
> - file descriptor locking. Currently, if you share file descriptors > among multiple processes (CLONE_FILES), and one process does a close() > on a file descriptor while another process is using that descriptor > for a read(), for example, the kernel can get rather upset.
Hmm, I'm using exactly this feature in a 2-threaded X11 application. Since my X toolkit is not thread-safe, all X calls are handled from the main thread, which communicates with the subthread only over a pipe. At one stage, I used to close the pipe from the subthread to make the main thread notice it having finished. Never got any kernel oopses.
But it seems I am somewhat lucky anyway, since I havent yet added any lock around malloc() etc. either -- I'm just using plain libc with clone() (actually a sprocsp() wrapper which is exactly your asm code snippet but without the stack memory leak). I would _expect_ this to crash with more busy threads.
>the fact that nobody has shown more than a lukewarm theoretical interest >means that I haven't felt that there was any reason to concentrate on >something that people don't really seem to be interested in.
Please, I am quite interested in this (and judging from several recent posts, I'm not alone).
Regards, Wolfram.
|  |