Re: wait()/alarm() race condition
On Sun, 30 Mar 2003, [ISO-8859-1] Mikko Työläjärvi wrote: > On Sun, 30 Mar 2003, Sean Hamilton wrote: > > > Dan Nelson wrote: > > | Just make sure your signal handler has the SA_RESTART flag unset > > | (either via siginterrupt() if the handler was installed with signal(), > > | or directly if the signal was installed with sigaction() ), and the > > | signal will interrupt the wait() call. > > > > Er, I think you've missed my problem. Or I'm not getting your solution. > > > > I'm concerned about this order of events: > > > > - alarm() > > - wait() returns successfully > > - if (alarmed...) [false] > > - SIGALRM is delivered, alarmed = true > > - loop > > - wait() waits indefinitely > > > > This is incredibly unlikely to ever happen, but it's irritating me somewhat > > that the code isn't airtight. Bad design. Surely there is some atomic means > > of setting a timeout on a system call. > > My stock solution to this kind of problem is to turn those pesky > signals into I/O and use an old fashioned select() loop to handle > them; create a pipe(2), let signal handlers write one-byte "messages" > (the signal number) into the pipe and then use select() to dequeue the > events (signals) from the pipe. > > Select() has a timeout parameter you can play with to your hearts > content, and provided you don't overflow the pipe, no events will > get lost. You'd have to install a hander for SIGCHLD, of course. Or how about kqueue(2) with EVFILT_SIGNAL. That would seem to be a more elegant solution. No signal handlers or alarm() required. -Brian -- Brian Buchanan, CISSP [EMAIL PROTECTED] -- FreeBSD - The Power to Serve! http://www.freebsd.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: wait()/alarm() race condition
Dan Nelson wrote: | In the last episode (Mar 30), Sean Hamilton said: || I'm concerned about this order of events: || || - alarm() || - wait() returns successfully || - if (alarmed...) [false] || - SIGALRM is delivered, alarmed = true || - loop || - wait() waits indefinitely | | A cleaner solution would be to use ualarm(6,1000) or setitimer() | to do this (replacing the alarm(60) call outside the handler). This looks like the way to go. "cleaner" is certainly relative here, but it's quite likely this hack never comes up in the lifetime of the program. I've inserted a printf just in case. (slight grin) This is my first time dealing with signals... they seem to lack the elegance most of Unix offers. Perhaps that's just my inexperience speaking. sh ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: wait()/alarm() race condition
In the last episode (Mar 30), Sean Hamilton said: > Dan Nelson wrote: > | Just make sure your signal handler has the SA_RESTART flag unset > | (either via siginterrupt() if the handler was installed with > | signal(), or directly if the signal was installed with sigaction() > | ), and the signal will interrupt the wait() call. > > Er, I think you've missed my problem. Or I'm not getting your solution. > > I'm concerned about this order of events: > > - alarm() > - wait() returns successfully > - if (alarmed...) [false] > - SIGALRM is delivered, alarmed = true > - loop > - wait() waits indefinitely You can probably do something like "alarm(1);" at the top of your handle_sigalarm function. That way after 60 seconds the alarm will fire every second until cleared. A cleaner solution would be to use ualarm(6,1000) or setitimer() to do this (replacing the alarm(60) call outside the handler). > This is incredibly unlikely to ever happen, but it's irritating me > somewhat that the code isn't airtight. Bad design. Surely there is > some atomic means of setting a timeout on a system call. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: wait()/alarm() race condition
On Sun, 30 Mar 2003, Sean Hamilton wrote: > Dan Nelson wrote: > | Just make sure your signal handler has the SA_RESTART flag unset > | (either via siginterrupt() if the handler was installed with signal(), > | or directly if the signal was installed with sigaction() ), and the > | signal will interrupt the wait() call. > > Er, I think you've missed my problem. Or I'm not getting your solution. > > I'm concerned about this order of events: > > - alarm() > - wait() returns successfully > - if (alarmed...) [false] > - SIGALRM is delivered, alarmed = true > - loop > - wait() waits indefinitely > > This is incredibly unlikely to ever happen, but it's irritating me somewhat > that the code isn't airtight. Bad design. Surely there is some atomic means > of setting a timeout on a system call. My stock solution to this kind of problem is to turn those pesky signals into I/O and use an old fashioned select() loop to handle them; create a pipe(2), let signal handlers write one-byte "messages" (the signal number) into the pipe and then use select() to dequeue the events (signals) from the pipe. Select() has a timeout parameter you can play with to your hearts content, and provided you don't overflow the pipe, no events will get lost. You'd have to install a hander for SIGCHLD, of course. $.02, /Mikko ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: wait()/alarm() race condition
Dan Nelson wrote: | Just make sure your signal handler has the SA_RESTART flag unset | (either via siginterrupt() if the handler was installed with signal(), | or directly if the signal was installed with sigaction() ), and the | signal will interrupt the wait() call. Er, I think you've missed my problem. Or I'm not getting your solution. I'm concerned about this order of events: - alarm() - wait() returns successfully - if (alarmed...) [false] - SIGALRM is delivered, alarmed = true - loop - wait() waits indefinitely This is incredibly unlikely to ever happen, but it's irritating me somewhat that the code isn't airtight. Bad design. Surely there is some atomic means of setting a timeout on a system call. sh ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: wait()/alarm() race condition
In the last episode (Mar 30), Sean Hamilton said: > [asked in comp.unix.programmer without much luck] > > I have a loop which calls wait(), and I want another function to be > called as close to once per minute as possible. Pseudo code: [snip] > My concern is there is a small possibility that the alarm signal is > delivered after the if() but before the wait. So it is possible that > this wait takes several minutes or longer. > > Moving the "if (alarmed)" above the wait() makes no difference, of course. > > Is there a better way of doing something like this? Ideally wait() has a > timeout parameter, but, no such luck. Just make sure your signal handler has the SA_RESTART flag unset (either via siginterrupt() if the handler was installed with signal(), or directly if the signal was installed with sigaction() ), and the signal will interrupt the wait() call. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [hackers] Re: Realtek
In message: <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Dag-Erling Smørgrav) writes: : address wrong to not finding it at all (I believe it reports "No : station address in CIS!") and refusing to attach. It always didn't find it, you just got lucky before. The no station address in CIS means that it can't map the CIS. This means the 'it' isn't dc, but rather 'cbb'. cbb's ability to map memory is kinda flakey on some machines. You have one. You need to set hw.cbb.start_memory to a value that makes your laptop happy. Yes, this sucks, but it is a symptom of the deeper problems with the dynamic allocation of resources in freebsd pci code. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [hackers] Re: Realtek
"M. Warner Losh" <[EMAIL PROTECTED]> writes: > In message: <[EMAIL PROTECTED]> > [EMAIL PROTECTED] (Dag-Erling Smørgrav) writes: > : Not to mention the fact that over the past year or so people have been > : repeatedly picking the dc driver apart and putting it back together > : with some bits missing, so for some cards it has gone from working > : perfectly, to getting the MAC address wrong but working fine after you > : manually set it, to plainly refusing to attach to the card. My laptop > : is now practically reduced to a doorstop since -STABLE doesn't have > : Cardbus support and -CURRENT refuses to attach to the NIC. > > As far as I know, all the sizing and weirdness issues have been worked > out with dc. Care to provide details on the card that isn't? It's an IBM branded Xircom card which used to work perfectly (except for some trouble with underruns which another nearly identical card didn't have... but I lost the dongle for that one). FRU 34L5309 if you want to look up the datasheet. About a year ago, subsequent to changes in the dc driver, -CURRENT started getting the MAC address wrong (but it would still attach, so I could set the correct MAC address manually). At some later point, some time between October 2002 and February 2003 (during which time I didn't run -CURRENT on the laptop due to insufficient disk space), it went from getting the MAC address wrong to not finding it at all (I believe it reports "No station address in CIS!") and refusing to attach. I have a couple of 16-bit cards lying around, but oldcard couldn't even find the slots, let alone the cards I put in. I haven't tried 4.8 as it would be useless for me (I need the laptop for development work on -CURRENT). The only alternative left is SLIP, which would prevent me from using the laptop as a serial console since it only has one port - but it turns out 5.0-RELEASE is unable to use the serial port. That may be a BIOS problem though, the BIOS seems to regularly reset random configuration options (such as the "IRDA, what IRDA? I don't need no stinking IRDA" option) to factory defaults. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [hackers] Re: Realtek
In message: <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Dag-Erling Smørgrav) writes: : Not to mention the fact that over the past year or so people have been : repeatedly picking the dc driver apart and putting it back together : with some bits missing, so for some cards it has gone from working : perfectly, to getting the MAC address wrong but working fine after you : manually set it, to plainly refusing to attach to the card. My laptop : is now practically reduced to a doorstop since -STABLE doesn't have : Cardbus support and -CURRENT refuses to attach to the NIC. As far as I know, all the sizing and weirdness issues have been worked out with dc. Care to provide details on the card that isn't? Alternatively, wanna swap me one of my working cards for it? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jiffy.
"Evan S." <[EMAIL PROTECTED]> writes: > I'm wondering if FreeBSD-current has anything similar to Linux jiffies? Yes, but it would be easier to answer your question if you told us what you need the information for. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [hackers] Re: Realtek
David Gilbert <[EMAIL PROTECTED]> writes: > But ... I'm not sure that their performance is largely better than the > rl's. The driver writer for the rl maligns the card in comments for > requiring alignment (and thus copying). There are far worse hacks in > the dc code ... with the comment that some dc implementations are > worse than others. Not to mention the fact that over the past year or so people have been repeatedly picking the dc driver apart and putting it back together with some bits missing, so for some cards it has gone from working perfectly, to getting the MAC address wrong but working fine after you manually set it, to plainly refusing to attach to the card. My laptop is now practically reduced to a doorstop since -STABLE doesn't have Cardbus support and -CURRENT refuses to attach to the NIC. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pam_ldap...
"Jacques A. Vidrine" <[EMAIL PROTECTED]> writes: > The part you are missing is that before you can authenticate, you must > have account and authorization information. For UNIX services, this > means that e.g. getpwnam() needs to find you. Nope - you don't need a struct passwd to call pam_authenticate(), and PAM supports the idea of a "template user" which is used to obtain a struct passwd for users that are authenticated through other means. PAM applications are supposed to call pam_get_user() once the user has been successfully authenticated to get the name of the template user. I think most PAM applications in the base system fail to do this. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
wait()/alarm() race condition
[asked in comp.unix.programmer without much luck]
Greetings,
I have a loop which calls wait(), and I want another function to be called
as close to once per minute as possible. Pseudo code:
int alarmed = 0;
void handle_sigalrm (int sig)
{
alarmed = 1;
}
while (1)
{
alarmed = 0;
alarm (60);
while (1)
{
wait (...);
if (alarmed || wait was interrupted)
{
break;
}
}
/* minutely code */
}
My concern is there is a small possibility that the alarm signal is
delivered after the if() but before the wait. So it is possible that this
wait takes several minutes or longer.
Moving the "if (alarmed)" above the wait() makes no difference, of course.
Is there a better way of doing something like this? Ideally wait() has a
timeout parameter, but, no such luck.
sh
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jiffy.
In article <[EMAIL PROTECTED]>, Evan S. <[EMAIL PROTECTED]> writes >Hello, > >I'm wondering if FreeBSD-current has anything similar to Linux jiffies? This level of question is probably best asked on freebsd-questions. That said, probably want you is: man 2 gettimeofday Tony ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
jiffy.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I'm wondering if FreeBSD-current has anything similar to Linux jiffies? Thanks, Evan :-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+h1pYECYZSrUV88QRAo9DAKDm6D40Z7/tYuseLzrKcQg669ic7gCgzxGS yyVDuJQlOWiMCWfWrKZEMNw= =Js9Y -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [hackers] Re: Realtek
> "Wes" == Wes Peters <[EMAIL PROTECTED]> writes: Wes> On Wednesday 26 March 2003 16:03, David Gilbert wrote: >> Given the price of this card ... and the fact that >> less-than-400Mhz CPU's are rather rare, and that this is only an >> issue for high bandwidth applications ... the rl cards might fit >> for you. Wes> Given the price of the card, you can almost always find a better Wes> one at roughly the same price. For instance, this one: Wes> dc0: port 0xd800-0xd87f mem Wes> 0xf300-0xf30003ff irq 7 at device 11.0 on pci0 Wes> was FREE last Christmas, from Office Depot. It's a Belkin Wes> branded card and normally sells for $10 (at TigerDirect.com). I was a fan of the dc drivers ... I think most sysadmins were. They were the early 4 port cards ... and then they were the cheap 4 port cards. I still see a few come along with prices in the $10 range from various vendors. But ... I'm not sure that their performance is largely better than the rl's. The driver writer for the rl maligns the card in comments for requiring alignment (and thus copying). There are far worse hacks in the dc code ... with the comment that some dc implementations are worse than others. Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BSD tar (was Re: Making pkg_XXX tools smarter about filetypes...)
Given ample personal experience with this issue, all I can say is that actions speak a lot louder than words where it's concerned. :-) I don't mean this in the usual and offensive "put up or shut up" sense either, believe it or not. It's just that I've seen literally years worth of discussion on this topic and all the threads generally wind up in exactly the same place: Everyone agrees that the format should support good compression, random access to contents (or at least a good and fast way of skipping over unwanted items), a library as well as command-line API for manipulation, rich and extensible metadata for file attributes/signatures/checksums/comments/etc etc, the usual laundry list. Then everyone starts pulling up various package file formats from the 70's and 80's (which is about when all of the current ones were designed) and arguing the pros and cons of each, none of which were exactly designed with the current range of file attributes and computing capabilities in mind so this leads to lots of "the foo format sucks!" kinds of comments. Eventually everyone gets tired and leaves the discussion for another few months/years. That is why the deadlock will only be broken by someone coming forward with a new file format AND implementation (library and command line API) on a plate, pointing to all of its obvious advantages and suitability for current needs and then seeking to evangelize that rather than getting trapped in the endless cycle of tar/zip/rar/zoo/arc/blah debates. - Jordan On Sunday, March 30, 2003, at 11:47 AM, Tim Kientzle wrote: I've given up trying to argue for a well-designed package file format. tar works well enough, I suppose. (Better than the oft-suggested 'zip' format. Ugh.) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BSD tar (was Re: Making pkg_XXX tools smarter about filetypes...)
Wes Peters wrote: On Friday 28 March 2003 22:47, Tim Kientzle wrote: With this [tar library], it should be possible to make pkg_add considerably more efficient. I'd much rather see the metadata moved outside the file archives, but that's a separate argument and in now way detracts from your proposed work. ;^) I've given up trying to argue for a well-designed package file format. tar works well enough, I suppose. (Better than the oft-suggested 'zip' format. Ugh.) Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [hackers] Re: Realtek
On Wednesday 26 March 2003 16:03, David Gilbert wrote: > > Given the price of this card > ... and the fact that less-than-400Mhz CPU's are rather rare, and that > this is only an issue for high bandwidth applications ... the rl cards > might fit for you. Given the price of the card, you can almost always find a better one at roughly the same price. For instance, this one: dc0: port 0xd800-0xd87f mem 0xf300-0xf30003ff irq 7 at device 11.0 on pci0 was FREE last Christmas, from Office Depot. It's a Belkin branded card and normally sells for $10 (at TigerDirect.com). -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
BSD tar (was Re: Making pkg_XXX tools smarter about file types...)
On Friday 28 March 2003 22:47, Tim Kientzle wrote:
>
> P.S. It's galled me for a while that pkg_add has
> to fork 'tar' to extract the archive.
Me too, me too.
> I've started
> piecing together a library that reads/writes tarfiles.
Excellent. A general design goal in userland should be to implement
functionality in libraries and then wrap small driver programs around
them to export the basic functionality to userland. I guess this partly
violates the original UNIX tools philosophy, but all it really does is
move it from the original pipes interfaces into the dynamic linker.
> With this, it should be possible to make pkg_add
> considerably more efficient. In particular, rather
> than extracting to a temp directory, then parsing important
> information, then moving the files, it should be
> possible using this library to read the initial
> entries ("+CONTENTS", in particular) directly into
> memory, process the information there, then extract the
> remainder of the package files directly into their
> final locations.
I'd much rather see the metadata moved outside the file archives, but
that's a separate argument and in now way detracts from your proposed
work. ;^)
> So far, I have a library API
> outlined, and functional read support implemented.
> Next step is to hack up a minimal tar implementation
> that uses it to make sure everything's working
> correctly.
>
> So far, the library automatically detects compression
> formats (using techniques like those in my
> pkg_install patch) and has some rough support
> for detecting the archive format as well.
> (One goal of mine: support for 'pax extended
> archives', which I understand can handle ACLs.)
I have wondered outloud before if pax might be a suitable starting place
for such a hacking expedition. Others who've worked on pax assure me it
is not. ;^( Sigh. So much code, so few programmers.
> Of course, such a library could also form the
> basis for a BSD-licensed tar to replace GNU tar.
> I understand a few people have wanted such a thing.
Why yes, yes they have.
--
Where am I, and what am I doing in this handbasket?
Wes Peters [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
