From owner-freebsd-questions Wed Jan 12 19:25:21 2000 Delivered-To: freebsd-questions@freebsd.org Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by hub.freebsd.org (Postfix) with ESMTP id 8BF0314BF5 for ; Wed, 12 Jan 2000 19:25:12 -0800 (PST) (envelope-from stuyman@confusion.net) Received: from confusion.net (user-2ive64q.dialup.mindspring.com [165.247.24.154]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id WAA07670 for ; Wed, 12 Jan 2000 22:24:43 -0500 (EST) Message-ID: <387D4549.2D3403C6@confusion.net> Date: Wed, 12 Jan 2000 22:23:53 -0500 From: Laurence Berland Reply-To: freebsd-questions@FreeBSD.ORG Organization: B.R.A.T.T. X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-questions@FreeBSD.ORG Subject: Re: Giving a sighandler more information References: <200001130234.DAA64583@dorifer.heim3.tu-clausthal.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Oliver Fromme wrote: > > Laurence Berland wrote in list.freebsd-questions: > > Followup question: is a sig_atomic_t appropriate to hold the value of a > > FILE * ? > > No. It is only guaranteed to be large enough to hold an int. > Of course, on intel PCs, a pointer has the same size as an int, > but not on other platforms (e.g. the Alpha). Therefore, > portable programs cannot store a pointer in a sig_atomic_t. > > Apart from that: You can't use a FILE* within a signal handler > anyway, because most of stdio's functions are not guaranteed to > be re-entrant. > > If you have to do something with a file within a signal > handler, use the lower-level file handling functions based on > file descriptors, i.e. open(), read(), write(), close(). > Conveniently, a file descriptor fits in a sig_atomic_t, too. > > Please refer to the sigaction(2) manpage, it contains a > complete list of all functions that are "async-signal safe". > All other functions are _not_ safe to use from within a signal > handler. > I take it it's equally unsafe if the signal handler calls a function that calls things outside of the async-safe list. The issue here is that I'm writing an ftp daemon for a compsci project, and I'm getting hung up on what to do when SIGURG is received as part of a TCP sync. Since I've been using stream based functions (fprintf fgets, etc.) I would hope to use those in the sighandler too. If that's not possible (or rather, not safe, as you indicate), how do you suggest I proceed? I suppose I could do a rewrite using combinations of snprintfs to format strings and read/write to do input output. This is certainly possible if necessary, but preferably avoidable. Any suggestions? > Regards > Oliver > Thanks to those who've been helping me so far, I've learned lots of stuff that I didn't know about signals before. You guys have been really helpful and I think you exemplify the sort of cooperation and helpfulness that makes the FreeBSD lists IMHO the best support lists on earth. -- Laurence Berland, Stuyvesant HS Debate <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> Windows 98: n. useless extension to a minor patch release for 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand for 1 bit of competition. http://stuy.debate.net icq #7434346 aol imer E1101 The above email Copyright (C) 2000 Laurence Berland All rights reserved To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message