Date: Wed, 12 Jan 2000 22:23:53 -0500 From: Laurence Berland <stuyman@confusion.net> To: freebsd-questions@FreeBSD.ORG Subject: Re: Giving a sighandler more information Message-ID: <387D4549.2D3403C6@confusion.net> References: <200001130234.DAA64583@dorifer.heim3.tu-clausthal.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Oliver Fromme wrote:
>
> Laurence Berland <stuyman@confusion.net> 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?
<aside>Is there a way to discover these various caveats to issues that
one with as little experience as I might find more easily?</aside>
> Regards
> Oliver
>
<thankyou>
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.
</thankyou>
--
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?387D4549.2D3403C6>