From owner-freebsd-hackers Sat May 17 21:03:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA07182 for hackers-outgoing; Sat, 17 May 1997 21:03:12 -0700 (PDT) Received: from freebsd1.cimlogic.com.au ([203.36.2.25]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA07177 for ; Sat, 17 May 1997 21:03:06 -0700 (PDT) Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.8.5/8.8.5) id OAA00506; Sun, 18 May 1997 14:04:47 GMT From: John Birrell Message-Id: <199705181404.OAA00506@freebsd1.cimlogic.com.au> Subject: Re: GNAT-pthreads integration bugs/questions In-Reply-To: <199705111316.IAA26518@iworks.InterWorks.org> from "Daniel M. Eischen" at "May 11, 97 08:16:41 am" To: deischen@iworks.InterWorks.org (Daniel M. Eischen) Date: Sun, 18 May 1997 14:04:46 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [ Sorry for the delay... new contract at work and MX problems] Daniel M. Eischen wrote: > > I've implemented Ada tasking in GNAT over FreeBSDs pthreads library. So > far everything seems to work great. Thanks to John Birrell for making > this possible! 8-) > > I did make some changes to the threads library and have a couple other > questions. > > Problems with pthreads (libc_r:/uthread): > > o pthreads.h doesn't reflect reality. Where are pthread_setschedparam > and pthread_getschedparam? I take it pthread_getprio and pthread_setprio > are to be used instead. The same for pthread_attr_setschedparam and > pthread_attr_getschedparam, but why is there only pthread_attr_setprio > and no pthread_attr_getprio. Ummm, no excuses... > > o Added pthread_attr_getprio (uthread/uthread_attr_getprio.c). > > o Added uthread_sigwait.c, uthread_attr_getprio.c, and > uthread_attr_setprio.c to Makefile.inc in libc_r/uthreads. > > Questions about layering the GNAT tasking runtime over FreeBSD threads: > > o There is a mechanism in the GNAT runtime to reserve signals so that > they will never allowed to be masked by an application. Like SIGVTALRM > because it is used by pthreads (setitimer/getitimer) for scheduling. > Pthreads doesn't seem to use SIGALRM, but I've reserved this signal also. No it doesn't. You can use it if you want to. > Is it safe to allow SIGALRM to be masked? Unless you try to do things with the _thread_sys_*() functions any masking you try to do will just affect the user-interface, not the thread library. > I've reserved SIGCHLD, > SIGSTOP, SIGKILL, and SIGINT. You can do that, but you don't need to. > > o The Ada language predefines the Constraint_Error and Storage_Error > exceptions. A Constraint_Error is raised for things like referencing > null pointers, division by zero, going outside the bounds of an > array, overflow, etc. A Storage_Error is typically raised when > an allocator requires more space than is available for a storage > pool. The GNAT runtime provides a signal handler to exception > raising mechanism. I've converted SIGFPE and SIGILL to Constraint_Error > and SIGSEGV and SIGBUS to Storage_Error. Is there anything in > sigcontext that would help to determine which exception should > really be raised? I hope someone else can answer that. > > Dan Eischen > deischen@iworks.InterWorks.org Regards, -- John Birrell - jb@cimlogic.com.au; jb@netbsd.org; jb@freebsd.org CIMlogic Pty Ltd, 119 Cecil Street, South Melbourne Vic 3205, Australia Tel +61 3 9690 6900 Fax +61 3 9690 6650 Mob +61 418 353 137