>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.