* task blocked using GNATSOCKETS @ 2003-10-03 9:52 Riccardo Fulcoli 2003-10-03 11:12 ` Jeff C, 2003-10-04 1:03 ` Craig Carey 0 siblings, 2 replies; 4+ messages in thread From: Riccardo Fulcoli @ 2003-10-03 9:52 UTC (permalink / raw) Hi there! I've got a problem. In a task in wich I use gnat sockets I cannot get one exception if an abnormal condition is presented. In particular if another program has already a socket on a particular address and port that I want to use no errors messages are presented but my task simply waits indefinitely. In the other hand if I use the same code in a procedure that is not a task I can get the exception: "raised GNAT.SOCKETS.SOCKET_ERROR : [125] Address already in use" I'm supposing this belongs by the fact that I'm using a task. Maybe I may copile with some kind of special flag?? Someone could help me? Tanks! Riccardo ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: task blocked using GNATSOCKETS 2003-10-03 9:52 task blocked using GNATSOCKETS Riccardo Fulcoli @ 2003-10-03 11:12 ` Jeff C, 2003-10-04 1:03 ` Craig Carey 1 sibling, 0 replies; 4+ messages in thread From: Jeff C, @ 2003-10-03 11:12 UTC (permalink / raw) "Riccardo Fulcoli" <kk@kk.com> wrote in message news:bljgud$s47$1@e3k.asi.ansaldo.it... > Hi there! > > I've got a problem. > In a task in wich I use gnat sockets I cannot get one exception if an > abnormal condition is presented. > > In particular if another program has already a socket on a particular > address and port that I want to use no errors messages are presented but my > task simply waits indefinitely. > > In the other hand if I use the same code in a procedure that is not a task I > can get the exception: > > "raised GNAT.SOCKETS.SOCKET_ERROR : [125] Address already in use" > > I'm supposing this belongs by the fact that I'm using a task. > > Maybe I may copile with some kind of special flag?? > > Someone could help me? > > Tanks! > > Riccardo > > Are you really sure that you are not getting the exception. Add a when others exception handler to your task that does a text IO.. If you have no exception handler and you get an exception in the task, the task will silently terminate. If you get one in "the procedure" (e.g. main program in a program with no tasks) the program will terminate and print the exception.. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: task blocked using GNATSOCKETS 2003-10-03 9:52 task blocked using GNATSOCKETS Riccardo Fulcoli 2003-10-03 11:12 ` Jeff C, @ 2003-10-04 1:03 ` Craig Carey 2003-10-22 8:58 ` Craig Carey 1 sibling, 1 reply; 4+ messages in thread From: Craig Carey @ 2003-10-04 1:03 UTC (permalink / raw) On Fri, 3 Oct 2003 11:52:27 +0200, "Riccardo Fulcoli" <kk@kk.com> wrote: ... >In particular if another program has already a socket on a particular >address and port that I want to use no errors messages are presented but my >task simply waits indefinitely. > >In the other hand if I use the same code in a procedure that is not a task I >can get the exception: > >"raised GNAT.SOCKETS.SOCKET_ERROR : [125] Address already in use" That could be a problem due to Linux. If Linux, some comment on FSU GNAT threads vs RTS threads would be appropriate. In Linux, netstat can be run (and in Windows, TCP Viewer of www.sysinternals.com), and that can show if the port number (interface) is locked up. The SO_REUSEADDR flag might possibly fix the program GS.Set_Socket_Option (Socket => So_Sock, Level => GS.Socket_Level, -- SOL_SOCKET Option => GS.Option_Type'( -- SO_REUSEADDR Name => GS.Reuse_Address, Enabled => Share), Error_Val => Error_Val); In Linux reducing the Time_Wait interval for a single socket does nothing. In Windows a port number can be bound to before another program actually released it. Then the other program can be killed. * create socket * bind to socket * when when no error * produce error message saying interface is in use or in Time_Wait state. * set SO_REUSEADDR * bind again (and reusing the same socket seems to no worse) Also every socket can have SO_REUSEADDR set. Then port numbers connected to, are not themselves locked up for 1 minute after the program (or fragment) quits. It seems to be a bug in Linux (maybe ported over from BSD). -- Zombie Ada program fragments can lock up sockets. There could be a special port number that all live and zombies GNAT Ada programs chat over, and their coordinate the killing of each other which then could free up port numbers. The GNAT Pro compiler seems to have a solution now. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9480 | FYI, in the ACT GNATpro version 5.00a, there is a new pragma | Interrupt_State which fixes this problem. | | When that pragma is inserted as shown below, the tasking program | can be killed via the TERM signal as expected: | | procedure Sigterm is | pragma Unreserve_All_Interrupts; | pragma Interrupt_State (SIGTERM, System); -- insert this line The 'killall' command can succesfully clean up after a Ctrl-C. Actually, this feature of Ada could speed up testing of university assignments: if the code starts but does not stop then there might be a rule allowing no further checking. Craig Carey ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: task blocked using GNATSOCKETS 2003-10-04 1:03 ` Craig Carey @ 2003-10-22 8:58 ` Craig Carey 0 siblings, 0 replies; 4+ messages in thread From: Craig Carey @ 2003-10-22 8:58 UTC (permalink / raw) An update to the GCC GNAT Ada 95 compiler (gcc.gnu.org) occurred on 20-21 October 2003. Now "pragma Interrupt_State". So perhaps now the whole program will die when Ctrl-C or 'kill -TERM' is done, in Linux. (I didn't check). On Sat, 04 Oct 2003 13:03:53 +1200, Craig Carey wrote: >On Fri, 3 Oct 2003 11:52:27 +0200, "Riccardo Fulcoli" wrote: ... >>"raised GNAT.SOCKETS.SOCKET_ERROR : [125] Address already in use" ... [Setting SO_REUSEADDR fixes locked-up sockets problems in Linux/BSD] ... >Zombie Ada program fragments ... ... > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9480 The bug report is on how kill -TERM does not kill all the pieces of a GNAT Ada program in Linux (and *BSD). > >| FYI, in the ACT GNATpro version 5.00a, there is a new pragma >| Interrupt_State which fixes this problem. >| >| When that pragma is inserted as shown below, the tasking program >| can be killed via the TERM signal as expected: >| >| procedure Sigterm is >| pragma Unreserve_All_Interrupts; >| pragma Interrupt_State (SIGTERM, System); -- insert this line > Getting GCC Ada using rsync (this excludes many non-Ada files): rsync -RPvacz --include '/gcc/gcc/ada' --exclude '/*/*/*' rsync://gcc.gnu.org/gcc-cvs . -~ Craig Carey ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-10-22 8:58 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-10-03 9:52 task blocked using GNATSOCKETS Riccardo Fulcoli 2003-10-03 11:12 ` Jeff C, 2003-10-04 1:03 ` Craig Carey 2003-10-22 8:58 ` Craig Carey
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox