should accept be protected with fport_wait_for_input?

should accept be protected with fport_wait_for_input?

[dskr]

Hi,

the fport fill input code provides a way to avoid some threaded  
deadlocks with fport_wait_for_input. I appreciate this tremendously!

Should this protection be extended to 'accept' in the socket code to  
prevent the entire runtime from blocking if a thread blocks on accept?

Cheers,
	Dan Ridge


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: should accept be protected with fport_wait_for_input?

[Marco Maggi]

Ciao,

"dskr" wrote:
>Should this protection be extended to 'accept' in the socket
>code to prevent the entire runtime from blocking if a thread
>blocks on accept?

I am not an expert in networking, but it seems to me that to
avoid blocking you need to make the server socket non-blocking.
I dunno what is you platform, but if you are using the
GNU C Library you can read the "accept" info node:

     The `accept' function waits if there are no connections
pending,
     unless the socket SOCKET has nonblocking mode set.
(You can use
     `select' to wait for a pending connection, with a
nonblocking
     socket.)  *Note File Status Flags::, for information about
     nonblocking mode.

HTH
--
Marco Maggi

"Now feel the funk blast!"
Rage Against the Machine - "Calm like a bomb"




_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: should accept be protected with fport_wait_for_input?

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 479 bytes --]

Hi,

dskr <dskr@mac.com> writes:

> the fport fill input code provides a way to avoid some threaded
> deadlocks with fport_wait_for_input. I appreciate this tremendously!
>
> Should this protection be extended to 'accept' in the socket code to
> prevent the entire runtime from blocking if a thread blocks on accept?

You're right, we should leave "guile mode" before blocking in
`accept(2)'.  I committed the attached patch, let me know if it works
for you.

Thanks!

Ludovic.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: The patch --]
[-- Type: text/x-diff, Size: 1051 bytes --]

--- orig/libguile/socket.c
+++ mod/libguile/socket.c
@@ -36,6 +36,8 @@
 #include "libguile/validate.h"
 #include "libguile/socket.h"
 
+#include "libguile/iselect.h"
+
 #ifdef __MINGW32__
 #include "win32-socket.h"
 #endif
@@ -1321,16 +1323,30 @@
 	    "connection and will continue to accept new requests.")
 #define FUNC_NAME s_scm_accept
 {
-  int fd;
+  int fd, selected;
   int newfd;
   SCM address;
   SCM newsock;
+  SELECT_TYPE readfds, exceptfds;
   socklen_t addr_size = MAX_ADDR_SIZE;
   scm_t_max_sockaddr addr;
 
   sock = SCM_COERCE_OUTPORT (sock);
   SCM_VALIDATE_OPFPORT (1, sock);
   fd = SCM_FPORT_FDES (sock);
+
+  FD_ZERO (&readfds);
+  FD_ZERO (&exceptfds);
+  FD_SET (fd, &readfds);
+  FD_SET (fd, &exceptfds);
+
+  /* Block until something happens on FD, leaving guile mode while
+     waiting.  */
+  selected = scm_std_select (fd + 1, &readfds, NULL, &exceptfds,
+			     NULL);
+  if (selected < 0)
+    SCM_SYSERROR;
+
   newfd = accept (fd, (struct sockaddr *) &addr, &addr_size);
   if (newfd == -1)
     SCM_SYSERROR;



[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user