From owner-freebsd-arch Mon Nov 1 16:32:26 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id F126A14DC4 for ; Mon, 1 Nov 1999 16:32:21 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id BAA10191 for ; Tue, 2 Nov 1999 01:32:20 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA76767 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 01:32:19 +0100 (MET) Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 88E3414DC4 for ; Mon, 1 Nov 1999 16:31:57 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id TAA15398 for ; Mon, 1 Nov 1999 19:27:17 -0500 (EST) Reply-To: Randell Jesup To: freebsd-arch@freebsd.org Subject: Re: Threads goals version III References: <19991101231743.F30501FD7@io.yi.org> From: Randell Jesup Date: 01 Nov 1999 20:28:26 +0000 In-Reply-To: Jake Burkholder's message of "Mon, 01 Nov 1999 15:17:42 -0800" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jake Burkholder writes: >int global; /* all threads can access this */ > >main() { > thread t1; > int mainvar; > > /* this could also be mmaped or stack based storage */ > t.stack = malloc(some memory); What's this for? Wouldn't each new thread have it's own stack space allocated by the thread library/kernel? (Perhaps according to size requests in new_thread, or just an automatically grown segment of the process (not thread) VM space.) Note: I haven't looked at Unix thread library details. > new_thread(&t1, foo, 1, &mainvar); >foo(int ac, ...) { > /* t1 now has access to mainvar through p */ > >The WHOLE address space is shared. You can pass around >pointers to stack based storage, but a new thread executes >a new start_routine, so it can't access variables from the >scope in which new_thread was called, only what get passed >into start_routine. Also, inter-thread IPC and implicit shared structures might include pointers to stack variables, such as for a synchronous request from another thread for data to be put into a buffer on the stack, such as: (pseudo-code) void bar(unsigned char *encoded_data, unsigned long encoded_data_len) { unsigned char buffer[1000]; msg->out_buffer = &buffer[0]; msg->out_buflen = sizeof(buffer); msg->in_buffer = encoded_data; msg->in_buflen = encoded_data_len; msg->command = DECODE_DATA; // do_message is synchronous, sends a message and waits for a reply do_message(decode_thread,msg); // do something with buffer data } What synchronization (semaphores, etc) and inter-thread messaging mechanisms are we thinking of? -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message