lkml.org 
[lkml]   [1996]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: clone() and pthreads?
From

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.


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.140 / U:0.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site