[9fans] libthread API

[9fans] libthread API

[anonymous]

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?

Re: [9fans] libthread API

[Gorka Guardiola]

On Fri, Jan 8, 2010 at 10:40 AM, anonymous <aim0shei@lavabit.com> wrote:
> Why libthread has threadcreate instead of something like fork? With

Preemptive vs cooperative.


--
- curiosity sKilled the cat

Re: [9fans] libthread API

[erik quanstrom]

On Fri Jan  8 23:31:23 EST 2010, paurea@gmail.com wrote:
> On Fri, Jan 8, 2010 at 10:40 AM, anonymous <aim0shei@lavabit.com> wrote:
> > Why libthread has threadcreate instead of something like fork? With
>
> Preemptive vs cooperative.

i think that misses the point of the question.  the question
could have just as easily been why not proccreate instead of
fork.

- erik

Re: [9fans] libthread API

[cinap_lenrek]

[-- 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?

Re: [9fans] libthread API

[anonymous]

Thanks, now I understand. The main question was why threadcreate asks
for function pointer and can't just leave me in my function like rfork.
So it is because we should move local variables out of scope as they
are no more valid cause we have a new completely clear stack.

But when it is better to use rfork with shared memory and when
libthread?

Re: [9fans] libthread API

[cinap_lenrek]

> Thanks, now I understand. The main question was why threadcreate asks
> for function pointer and can't just leave me in my function like rfork.
> So it is because we should move local variables out of scope as they
> are no more valid cause we have a new completely clear stack.
yes.

> But when it is better to use rfork with shared memory and when
> libthread?
depends. but in the majority of cases you want to use libthread because
it also gives you synchronization primitives like channels and has
co-routines called threads wich run cooperatively in a real system
proc.

but nobody forces you to use libthread. you can just use system primitives
like rendezvous, qlocks, pipes and shared memory with rfork.

--
cinap

Re: [9fans] libthread API

[Bruce Ellis]

ahh my wise, cold, east german friend.

good answer and fluffy agrees.

brucee

On 1/9/10, cinap_lenrek@gmx.de <cinap_lenrek@gmx.de> wrote:
> > Thanks, now I understand. The main question was why threadcreate asks
> > for function pointer and can't just leave me in my function like rfork.
> > So it is because we should move local variables out of scope as they
> > are no more valid cause we have a new completely clear stack.
> yes.
>
> > But when it is better to use rfork with shared memory and when
> > libthread?
> depends. but in the majority of cases you want to use libthread because
> it also gives you synchronization primitives like channels and has
> co-routines called threads wich run cooperatively in a real system
> proc.
>
> but nobody forces you to use libthread. you can just use system primitives
> like rendezvous, qlocks, pipes and shared memory with rfork.
>
> --
> cinap
>
>
>