Re: [9fans] libthread API

[cinap_lenrek@gmx.de]

[-- Attachment #1: Type: text/plain, Size: 642 bytes --]

the threads and procs that are created by libthread have ther stacks
malloc()ed, so one thread can allocate a structure or buffer on its
stack and pass a pointer to another thread or proc.  when you would do
a rfork(RFMEM) in a libthread program, the stacks would have been
shared by parent and child! libthread does some setjmp/longjmp magic to
switch the stack to the original plan9 stack segment to be able todo
a real rfork when spawning new procs.

also linux clone syscall takes a pointer to the routine running
in a new "thread" for a similar reason. they dont have the concept
of a always copy-on-write stack.

--
cinap

[-- Attachment #2: Type: message/rfc822, Size: 3291 bytes --]

From: anonymous <aim0shei@lavabit.com>
To: 9fans@9fans.net
Subject: [9fans] libthread API
Date: Fri, 8 Jan 2010 12:40:14 +0300
Message-ID: <20100108094014.GA16595@machine>

Why libthread has threadcreate instead of something like fork? With
threadcreate you should make struct to pass more than one argument and
pass a pointer to it.

I also see no problem with recieving different values for each thread.
Memory is shared, but return value is stored in register (accumulator
register for x86) which is not shared.

Maybe it was made for compatibility with Alef? In Alef it is possible
to return mulitply values, maybe they are stored in memory. But there
is rfork with RFMEM flag and it has no problem.

And by the way when libthread should be used and when rfork(RFMEM) is
better?