On Thu, 2006-11-09 at 22:56 +1100, Jonathan Kelly wrote: > well, I'm not really up on all the signal semantics and/or implications > ... I guess the idea is to do as little as possible in the handler then > ... the signal handler sets something so the system can find out that > something has changed and act appropriately ... but it means coding all > the routines to check for a change instead of dealing with it when it > happens, if dealing with it in the handler is a no-go... I wasn't really > thinking that far ahead ... I just wanted to be able to catch the signal > so I could experiment, and learn ...
A interrupt comes in at a random time, in the middle of the CPU doing something else. It cannot wait for the CPU to finish doing those other things .. because it has pre-empted them. A signal is a software interrupt, but has the same relation to a process as a hardware interrupt does to a CPU. A signal cannot know what state the stack (or heap) is in when it happens .. so the only place it can read/write data is global storage (C 'extern' or 'static' variables). SIGWINCH notifies a change in the controlling terminal size. Under Unix there can only be one controlling terminal. So you can write C code to toggle a flag. Then a pthread can sleep -- check the flag .. sleep .. check .. when the flag changes it disables interrupts, resets the flag, enable interrupts again, and then does some work. Disabling interrupts prevents one coming in having a race with the pthread to see if it can set the flag again before the pthread clears it. If a signal gets in before interrupts are disabled .. the flag will get set and interrupt exit before the pthread proceeds .. so you would lose one event. Usually this doesn't matter .. if it does, you have a problem anyhow, because events are coming in faster than you can service them. Another trick is to disable interrupts, sleep, then enable and disable interrupts .. if the interrupt is buffered it will occur right between the enable and disable. I recommend you do something lame and don't worry too much. Felix has a way to handle asynchronous event built in, the support is in the async I/O library suite faio and demux. This has a lot of nasty C++ written by RF, whose consideration of signals was itself interrupted by a holiday :) The system already handles certain event notifications for sockets, and has a way to propagate asynchronous events into the synchronous subsystem along channels, using supervisor calls (svc primitive). All this code is OS dependent and rather nasty (because the underlying OS are messy). -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
