From owner-state-threads@oss.sgi.com Wed Jun 28 11:08:54 2000 Received: by oss.sgi.com id ; Wed, 28 Jun 2000 11:08:35 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:42297 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 28 Jun 2000 11:08:11 -0700 Received: from metrostar.engr.sgi.com (metrostar.engr.sgi.com [163.154.38.57]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id LAA02924 for ; Wed, 28 Jun 2000 11:03:22 -0700 (PDT) mail_from (genes@metrostar.engr.sgi.com) Received: (from genes@localhost) by metrostar.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA10841 for state-threads@oss.sgi.com; Wed, 28 Jun 2000 10:54:44 -0700 From: "Gene Shekhtman" Message-Id: <10006281054.ZM10839@metrostar.engr.sgi.com> Date: Wed, 28 Jun 2000 10:54:43 -0700 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: state-threads@oss.sgi.com Subject: State Threads library Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: The State Threads library project is now up on SGI's Open Source site! http://oss.sgi.com/projects/state-threads/ Your contributions and comments are always welcome. -- Gene Shekhtman genes@sgi.com Internet Systems Engineering 650-933-8676 Silicon Graphics, Inc. From owner-state-threads@oss.sgi.com Mon Jul 24 10:09:20 2000 Received: by oss.sgi.com id ; Mon, 24 Jul 2000 10:09:10 -0700 Received: from [216.13.73.251] ([216.13.73.251]:1031 "EHLO mail.wiband.com") by oss.sgi.com with ESMTP id ; Mon, 24 Jul 2000 10:08:47 -0700 Received: from comm_server. (207107112115.wiband.com [207.107.112.115]) by mail.wiband.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id PRWR6VFP; Mon, 24 Jul 2000 11:50:49 -0500 Received: from [205.207.240.138] by comm_server.pronexus.com (NTMail 4.30.0012/NT2347.00.601c6109) with ESMTP id sguhaaaa for ; Mon, 24 Jul 2000 13:10:21 -0400 Received: by localhost with Microsoft MAPI; Mon, 24 Jul 2000 13:07:39 -0400 Message-ID: <01BFF570.250ACBB0.rae@pronexus.com> From: Ian Rae Reply-To: "rae@pronexus.com" To: "'state-threads@oss.sgi.com'" Subject: StateThreads for WinNT? Date: Mon, 24 Jul 2000 13:07:37 -0400 Organization: Pronexus X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: Is anyone interested in an WinNT port of StateThreads? I've started looking at it, and could use some help disabling C++ stack unwinding in my malloc'd stacks. TIA, --Ian Rae From owner-state-threads@oss.sgi.com Thu Jul 27 16:09:20 2000 Received: by oss.sgi.com id ; Thu, 27 Jul 2000 16:09:10 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:51303 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 27 Jul 2000 16:09:02 -0700 Received: from trudge.engr.sgi.com (trudge.engr.sgi.com [163.154.38.51]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA01846; Thu, 27 Jul 2000 16:14:58 -0700 (PDT) mail_from (mja@trudge.engr.sgi.com) Received: (from mja@localhost) by trudge.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id QAA80488; Thu, 27 Jul 2000 16:08:41 -0700 (PDT) From: mja@trudge.engr.sgi.com (Mike Abbott) Message-Id: <200007272308.QAA80488@trudge.engr.sgi.com> Subject: Patch for Apache/2.0a4 available To: apache@oss.sgi.com, state-threads@oss.sgi.com, new-httpd@apache.org Date: Thu, 27 Jul 2000 16:08:41 -0700 (PDT) Reply-To: mja@sgi.com X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: The Accelerating Apache Project is pleased to announce the availability of its enhancements for Apache/2.0a4, including an all new state-threaded multi-processing module that's faster than any standard Apache/2.0 MPM. Accelerating Apache Project: http://oss.sgi.com/projects/apache/ State Threads Library: http://oss.sgi.com/projects/state-threads/ -- Michael J. Abbott mja@sgi.com http://reality.sgi.com/mja/ From owner-state-threads@oss.sgi.com Thu Jul 27 19:41:22 2000 Received: by oss.sgi.com id ; Thu, 27 Jul 2000 19:41:12 -0700 Received: from twinlark.arctic.org ([204.107.140.52]:48904 "HELO twinlark.arctic.org") by oss.sgi.com with SMTP id ; Thu, 27 Jul 2000 19:41:00 -0700 Received: (qmail 31254 invoked by uid 500); 28 Jul 2000 02:41:02 -0000 Date: Thu, 27 Jul 2000 19:41:02 -0700 (PDT) From: dean gaudet To: new-httpd@apache.org, mja@sgi.com cc: apache@oss.sgi.com, state-threads@oss.sgi.com Subject: Re: Patch for Apache/2.0a4 available In-Reply-To: <200007272308.QAA80488@trudge.engr.sgi.com> Message-ID: X-comment: visit http://arctic.org/~dean/legal for information regarding copyright and disclaimer. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: yay, it's the hybrid threading model. i'm stoked that 2.0 made this easy for you -- it's exactly one of the applications i envisioned with the mpm architecture. oh and it's based on NSPR. heh. i love how things come full circle. thanks mike (and sgi)! -dean On Thu, 27 Jul 2000, Mike Abbott wrote: > The Accelerating Apache Project is pleased to announce the > availability of its enhancements for Apache/2.0a4, including an all > new state-threaded multi-processing module that's faster than any > standard Apache/2.0 MPM. > > Accelerating Apache Project: > http://oss.sgi.com/projects/apache/ > > State Threads Library: > http://oss.sgi.com/projects/state-threads/ > -- > Michael J. Abbott mja@sgi.com http://reality.sgi.com/mja/ > From owner-state-threads@oss.sgi.com Sat Jul 29 10:24:04 2000 Received: by oss.sgi.com id ; Sat, 29 Jul 2000 10:23:54 -0700 Received: from relay.a1.nl ([213.171.64.11]:35183 "EHLO relay.a1.nl") by oss.sgi.com with ESMTP id ; Sat, 29 Jul 2000 10:23:31 -0700 Received: from mail.a1.nl ([213.171.64.3]) by relay.a1.nl (980427.SGI.8.8.8/8.8.8) with ESMTP id TAA54060 for ; Sat, 29 Jul 2000 19:23:46 +0200 (MEST) Received: from a1.nl (dialup-66-123.a1.nl [213.171.66.123]) by mail.a1.nl (8.9.1a/8.9.1) with ESMTP id TAA13195 for ; Sat, 29 Jul 2000 19:23:44 +0200 (MET DST) Message-ID: <398313B8.8F1C0C0B@a1.nl> Date: Sat, 29 Jul 2000 19:26:16 +0200 From: Erik Hofman Reply-To: emh@a1.nl Organization: Eric's Conspirency Secret Service X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5 IP32) MIME-Version: 1.0 To: state-threads@oss.sgi.com Subject: Patch: gcc and Irix Content-Type: multipart/mixed; boundary="------------EDAA93479C1D4ACF10980554" Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: This is a multi-part message in MIME format. --------------EDAA93479C1D4ACF10980554 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I've created a small patch tbe enable to user gcc under Irix. Regards, Erik Hofman --------------EDAA93479C1D4ACF10980554 Content-Type: application/x-gzip; name="st-1.0-irix_gcc.diff.gz" Content-Disposition: inline; filename="st-1.0-irix_gcc.diff.gz" Content-Transfer-Encoding: base64 H4sICDISgzkAA3N0LTEuMC1pcml4X2djYy5kaWZmAIWS32+iQBDHn52/YkJ8kKxc2IXaK4mJ CtbjjupF27QPTQxXF7s5ihYl19xff7sKCEp6+0BmduczP76MYRh4F/7mkYj5l00q1q1HvsLv WYLURmY5luWY0jBNEwghZWhrEe5lVIzsBumNQ786V3nUYIDGNev2kMjvNQ4GgPXzus0+jBX/ la2P5ma7F2/ir6xanOdGpGdXKelVwQtEpOLDSCyWM6V7gp6BNCDrl5cqotwq0lSlbKzwPm0s Fkk5/9E+F+AC2ewimhMHs0kxJTtlZpeaSCijXXqUfjjyb4Ph5BDUR6UAIE9WIgKcD6eBP8L8 aZ9mHIiI+Dt22p3ZQu+iP/eflhPX1YG47qmbPkpRgHjjW386XhSZPRUNJPBUufJ29xqmfAVk dv9tPF8en+T1YxjHQHi844DuCZBP7U7esY7Gm9juLMB6ympAnh3PskdZHP8J06SYlOQDA9bG C/zpw5N+nr9IqvRktq32mF0xJauSs9Xu3A1/jHWcLfqamljD0YMfeH3NG000aFgz5zNo9vNe k6LX9s4BcgGov1CvRC6387/goVp9ZZu6W/bspqmqe+3AP5Explo3BAAA --------------EDAA93479C1D4ACF10980554-- From owner-state-threads@oss.sgi.com Fri Aug 25 13:45:40 2000 Received: by oss.sgi.com id ; Fri, 25 Aug 2000 13:45:30 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:40020 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 25 Aug 2000 13:44:59 -0700 Received: from metrostar.engr.sgi.com (metrostar.engr.sgi.com [163.154.38.57]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id NAA01884 for ; Fri, 25 Aug 2000 13:50:39 -0700 (PDT) mail_from (genes@metrostar.engr.sgi.com) Received: (from genes@localhost) by metrostar.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA13090 for state-threads@oss.sgi.com; Fri, 25 Aug 2000 13:25:02 -0700 From: "Gene Shekhtman" Message-Id: <10008251325.ZM13088@metrostar.engr.sgi.com> Date: Fri, 25 Aug 2000 13:25:02 -0700 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: state-threads@oss.sgi.com Subject: (Fwd) AAP patch for 2.0a6 available Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: Just forwarding Mike's announcement. --- Forwarded mail from mja@engr.sgi.com (Mike Abbott) From: mja@engr.sgi.com (Mike Abbott) Subject: AAP patch for 2.0a6 available To: apache@oss.sgi.com Date: Thu, 24 Aug 2000 14:20:20 -0700 (PDT) Cc: new-httpd@apache.org The Accelerating Apache Project announces the availability of its enhancements for Apache/2.0a6. http://oss.sgi.com/projects/apache/ We also are pleased to report that on a dual Pentium III Linux 2.4 system our state-threaded MPM is 25% faster than the dexter MPM, which uses a similar process/thread architecture with pthreads. -- Michael J. Abbott mja@sgi.com http://reality.sgi.com/mja/ ---End of forwarded mail from mja@engr.sgi.com (Mike Abbott) -- Gene Shekhtman genes@sgi.com Internet Systems Engineering 650-933-8676 Silicon Graphics, Inc. From owner-state-threads@oss.sgi.com Wed Sep 13 07:18:50 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 07:18:40 -0700 Received: from internal.mail.demon.net ([193.195.224.3]:25754 "EHLO internal.mail.demon.net") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 07:18:24 -0700 Received: from gwhdemnts03.server.demon.net (gwhdemnts03.server.demon.net [193.195.224.75]) by internal.mail.demon.net with ESMTP id PAA10312; Wed, 13 Sep 2000 15:18:22 +0100 (BST) Received: by gwhdemnts03.server.demon.net with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Sep 2000 15:18:22 +0100 Message-ID: <9B16CD9CFF9CD311B782009027D0D39301DB1CDB@gwhdemnts02.server.demon.net> From: "Kiernan, Alex" To: "'state-threads@oss.sgi.com'" Subject: Proxy failure on ECONNABORTED Date: Wed, 13 Sep 2000 15:18:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: I was playing with the proxy example with state threads & managed to get one of the processes to die (dual CPU box). Whats happened was the accept() call returned with ECONNABORTED (this is on Solaris 7) which caused the caller to bug out. My immediate reaction was to change if (errno == EINTR) to if (errno == EINTR || errno == ECONNABORTED) in st_accept(), but I'm not convinced thats the right fix (OK it needs some ifdefing around it, but I was thinking more of where this is "the right fix"). -- Alex Kiernan, Principal Engineer, Development, Thus PLC From owner-state-threads@oss.sgi.com Wed Sep 13 13:35:41 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 13:35:21 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:5737 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 13:34:57 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA09306 for ; Wed, 13 Sep 2000 13:27:16 -0700 (PDT) mail_from (genes@metrostar.engr.sgi.com) Received: from metrostar.engr.sgi.com (metrostar.engr.sgi.com [163.154.38.57]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id NAA23415 for ; Wed, 13 Sep 2000 13:34:25 -0700 (PDT) Received: (from genes@localhost) by metrostar.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA09625; Wed, 13 Sep 2000 13:13:34 -0700 From: "Gene Shekhtman" Message-Id: <10009131313.ZM9623@metrostar.engr.sgi.com> Date: Wed, 13 Sep 2000 13:13:34 -0700 In-Reply-To: "Kiernan, Alex" "Proxy failure on ECONNABORTED" (Sep 13, 3:18pm) References: <9B16CD9CFF9CD311B782009027D0D39301DB1CDB@gwhdemnts02.server.demon.net> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Kiernan, Alex" Subject: Re: Proxy failure on ECONNABORTED Cc: "'state-threads@oss.sgi.com'" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: On Sep 13, 3:18pm, Kiernan, Alex wrote: > Subject: Proxy failure on ECONNABORTED > I was playing with the proxy example with state threads & managed to get one > of the processes to die (dual CPU box). Whats happened was the accept() call > returned with ECONNABORTED (this is on Solaris 7) which caused the caller to > bug out. > > My immediate reaction was to change > > if (errno == EINTR) > > to > > if (errno == EINTR || errno == ECONNABORTED) > > in st_accept(), but I'm not convinced thats the right fix (OK it needs some > ifdefing around it, but I was thinking more of where this is "the right > fix"). > I think that applications should deal with those types of errors and not the library. That is, you need to modify proxy.c (which is just an example) to handle ECONNABORTED the way you want it. Something along the lines: .... cli_nfd = st_accept(srv_nfd, (struct sockaddr *)&cli_addr, &n, -1); if (cli_nfd == NULL) { /* Ignore ECONNABORTED */ if (errno == ECONNABORTED) continue; print_sys_error("st_accept"); exit(1); } .... In other words, treat st_accept() the same way as accept(3). Gene -- Gene Shekhtman genes@sgi.com Internet Systems Engineering 650-933-8676 Silicon Graphics, Inc. From owner-state-threads@oss.sgi.com Wed Sep 13 22:16:38 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 22:16:17 -0700 Received: from internal.mail.demon.net ([193.195.224.3]:59867 "EHLO internal.mail.demon.net") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 22:15:58 -0700 Received: from gwhdemnts03.server.demon.net (gwhdemnts03.server.demon.net [193.195.224.75]) by internal.mail.demon.net with ESMTP id GAA00921; Thu, 14 Sep 2000 06:15:44 +0100 (BST) Received: by gwhdemnts03.server.demon.net with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Sep 2000 06:15:43 +0100 Message-ID: <9B16CD9CFF9CD311B782009027D0D39301DB1CE1@gwhdemnts02.server.demon.net> From: "Kiernan, Alex" To: "'Gene Shekhtman'" Cc: "'state-threads@oss.sgi.com'" Subject: RE: Proxy failure on ECONNABORTED Date: Thu, 14 Sep 2000 06:15:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: > > My immediate reaction was to change > > > > if (errno == EINTR) > > > > to > > > > if (errno == EINTR || errno == ECONNABORTED) > > > > in st_accept(), but I'm not convinced thats the right fix > (OK it needs some > > ifdefing around it, but I was thinking more of where this > is "the right > > fix"). > > > > I think that applications should deal with those types of > errors and not the > library. That is, you need to modify proxy.c (which is just > an example) > to handle ECONNABORTED the way you want it. Something along > the lines: > > .... > cli_nfd = st_accept(srv_nfd, (struct sockaddr > *)&cli_addr, &n, -1); > if (cli_nfd == NULL) { > /* Ignore ECONNABORTED */ > if (errno == ECONNABORTED) > continue; > print_sys_error("st_accept"); > exit(1); > } > .... > > In other words, treat st_accept() the same way as accept(3). > Thanks, that was the steer I needed. -- Alex Kiernan, Principal Engineer, Development, Thus PLC From owner-state-threads@oss.sgi.com Mon Sep 18 10:45:11 2000 Received: by oss.sgi.com id ; Mon, 18 Sep 2000 10:45:02 -0700 Received: from multivac.xs4all.nl ([194.109.254.17]:33009 "EHLO helena.tux.nu") by oss.sgi.com with ESMTP id ; Mon, 18 Sep 2000 10:44:29 -0700 Received: from helena (IDENT:matthijs@localhost [127.0.0.1]) by helena.tux.nu (8.9.3/8.8.7) with SMTP id TAA05115 for ; Mon, 18 Sep 2000 19:45:22 +0200 From: Matthijs Sypkens Smit To: state-threads@oss.sgi.com Subject: problem with unpredictable values of variable Date: Mon, 18 Sep 2000 19:45:21 +0200 X-Mailer: KMail [version 1.1.94] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <00091819452102.04770@helena> Content-Transfer-Encoding: 8bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: Hi all, I'm very interested in using the state-threads library or actually the server-example that's implemented with this library, but I'm experiencing some troubles. I have quite some experience in coding C, but little experience with either threads or tcp/ip programming in C. The problem is this: I've tried to modifiy the server example to be able to return inputted strings in uppercase. Herefor I changed handle_session(...) to look like this: --- void handle_session(long srv_socket_index, st_netfd_t cli_nfd) { char buf[512]; struct in_addr *from = st_netfd_getspecific(cli_nfd); if (st_read(cli_nfd, buf, sizeof(buf), SEC2USEC(REQUEST_TIMEOUT)) < 0) { err_sys_report(errfd, "WARN: can't read request from %s: st_read", inet_ntoa(*from)); return; } if (st_write(cli_nfd, to_uppercase(buf), strlen(buf), -1) == -1) { err_sys_report(errfd, "WARN: can't write response to %s: st_write", inet_ntoa(*from)); return; } RQST_COUNT(srv_socket_index)++; } --- and added the function: --- char* to_uppercase(char *string) { int i; for (i = 0; string[i] != '\0'; i++) string[i] = toupper(string[i]); return string; } --- This seemed to work at first, but today I discovered that the array of characters `buf' sometimes later on contained text I had inputted earlier, but in uppercase. I suspect that I'm either making a dumb mistake or are totally missing some vital concept here. Might using '\0' not be a smart way to determine the end of a string or am I making some off-by-one error which causes this? To further demonstrate the problem, the following examples: An example of a working session is: --- [matthijs@helena /tmp]$ telnet helena 8000 Trying 192.168.79.13... Connected to helena. Escape character is '^]'. test TEST Connection closed by foreign host. --- Sometimes something like this happens: --- [matthijs@helena /tmp]$ telnet helena 8000 Trying 192.168.79.13... Connected to helena. Escape character is '^]'. test TEST T IS EEN MEGA-LANGE-TEST. EENS ZIEN WAT HIER GAAT GEBEUREN Connection closed by foreign host. --- Here `T IS EEN MEGA-LANGE-TEST. EENS ZIEN WAT HIER GAAT GEBEUREN' is something I typed in earlier in lowercase. I don't understand why this would happen and I'm not even sure that this has to do with (the threading of) the state-threads library. I sure hope someone can shed some light at this problem. TIA, -- Matthijs From owner-state-threads@oss.sgi.com Mon Sep 18 13:12:02 2000 Received: by oss.sgi.com id ; Mon, 18 Sep 2000 13:11:52 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:47202 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 18 Sep 2000 13:11:31 -0700 Received: from metrostar.engr.sgi.com (metrostar.engr.sgi.com [163.154.38.57]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id NAA22407 for ; Mon, 18 Sep 2000 13:03:49 -0700 (PDT) mail_from (genes@metrostar.engr.sgi.com) Received: (from genes@localhost) by metrostar.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA16002; Mon, 18 Sep 2000 12:51:48 -0700 From: "Gene Shekhtman" Message-Id: <10009181251.ZM16000@metrostar.engr.sgi.com> Date: Mon, 18 Sep 2000 12:51:48 -0700 In-Reply-To: Matthijs Sypkens Smit "problem with unpredictable values of variable" (Sep 18, 7:45pm) References: <00091819452102.04770@helena> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Matthijs Sypkens Smit Subject: Re: problem with unpredictable values of variable Cc: state-threads@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: On Sep 18, 7:45pm, Matthijs Sypkens Smit wrote: > Subject: problem with unpredictable values of variable > .... > > The problem is this: > I've tried to modifiy the server example to be able to return inputted > strings in uppercase. Herefor I changed handle_session(...) to look like this: > --- > void handle_session(long srv_socket_index, st_netfd_t cli_nfd) { > char buf[512]; > > struct in_addr *from = st_netfd_getspecific(cli_nfd); > > if (st_read(cli_nfd, buf, sizeof(buf), SEC2USEC(REQUEST_TIMEOUT)) < 0) { > err_sys_report(errfd, "WARN: can't read request from %s: st_read", > inet_ntoa(*from)); > return; > } > > if (st_write(cli_nfd, to_uppercase(buf), strlen(buf), -1) == -1) { > err_sys_report(errfd, "WARN: can't write response to %s: st_write", > inet_ntoa(*from)); > return; > } > > RQST_COUNT(srv_socket_index)++; > } > --- > and added the function: > --- > char* to_uppercase(char *string) { > int i; > > for (i = 0; string[i] != '\0'; i++) > string[i] = toupper(string[i]); > > return string; > } > --- > > This seemed to work at first, but today I discovered that the array of > characters `buf' sometimes later on contained text I had inputted earlier, > but in uppercase. I suspect that I'm either making a dumb mistake or are > totally missing some vital concept here. > Matthijs, The st_read() function (just like read(2)) returns the number of bytes read and doesn't do '\0'-termination. If you want to manipulate `buf' as a string, you need to terminate it yourself: void handle_session(long srv_socket_index, st_netfd_t cli_nfd) { char buf[512]; int n; struct in_addr *from = st_netfd_getspecific(cli_nfd); if ((n = st_read(cli_nfd, buf, sizeof(buf), SEC2USEC(REQUEST_TIMEOUT))) < 0) { err_sys_report(errfd, "WARN: can't read request from %s: st_read", inet_ntoa(*from)); return; } /* '\0'-terminate the buffer */ buf[n] = '\0'; if (st_write(cli_nfd, to_uppercase(buf), strlen(buf), -1) == -1) { err_sys_report(errfd, "WARN: can't write response to %s: st_write", inet_ntoa(*from)); return; } RQST_COUNT(srv_socket_index)++; } Hope it helps, Gene -- Gene Shekhtman genes@sgi.com Internet Systems Engineering 650-933-8676 Silicon Graphics, Inc. From owner-state-threads@oss.sgi.com Mon Sep 25 15:07:37 2000 Received: by oss.sgi.com id ; Mon, 25 Sep 2000 15:07:27 -0700 Received: from multivac.xs4all.nl ([194.109.254.17]:28666 "EHLO helena.tux.nu") by oss.sgi.com with ESMTP id ; Mon, 25 Sep 2000 15:07:08 -0700 Received: from helena (IDENT:matthijs@localhost [127.0.0.1]) by helena.tux.nu (8.9.3/8.8.7) with SMTP id AAA06416 for ; Tue, 26 Sep 2000 00:08:03 +0200 From: Matthijs Sypkens Smit To: state-threads@oss.sgi.com Subject: per-thread global variables Date: Tue, 26 Sep 2000 00:08:01 +0200 X-Mailer: KMail [version 1.1.94.2] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <00092600080101.06092@helena> Content-Transfer-Encoding: 8bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: Hi all, I'm currently working on a project to create a client-server implementation of a differential equation analysis tool. It is supposed to be a combination of a Java applet for defining, showing en editing systems and a deamon for providing methods of integration and computing-power. Since it must be able to handle more connections (by different users) simultaneously, I thought the state thread lib would be very useful for this. I took the server-example and played with it a little, which brought me to the following question: What is the best way to handle data that is needed by many functions, but is different on a connection basis? I'll expand on that. As long as the user is logged in on the server with the applet, there's an open connection which provides for a permanent/continous means of communcation. Once the connection is established many variables have to kept track of, for instance the definitions of multiple systems of differential equations and their solutions. Every user can input his own systems so every thread that handles a connection has a different set of data (which is different in size as well). A great deal of this data needs to be accessed by many routines. To me it looks therefor logical to have this data global to every controling thread, but not to the others. What are my options? I don't think it's possible to just define globals in my redefinition of handle_connection() (in a seperate c-file), because --if I understand things correctly-- this data would be the same for every thread. I saw in the documentation a section "Per-Thread Private Data" with four routines probably exactly for this issue. Is this what I need or are there other options? Is using these methods practical even for large amount of data (variables)? (and how does that actually work? I'm not sure I understand...) The last option I can conceive of is passing all the necessary variables to the routines that need them. Might it be a sign of bad design if this seems to over-complicate the code with many function-parameters? At this time it's hard to say how many variables actually need to be passed to how many funtions and what the level of (im)practicality is, because this still needs to be evaluated. I'm not sure yet how big a problem this might pose. This might be more of a issue of the C language than of the state-thread library, but considering that there're some people around here with experience in this field I took my chances. I know that it might be hard to say something about this, considering you don't have a detailed idea of how things are supposed to work and so on, but any insights and/or comments are appreciated, TIA, -- Matthijs ** Do you know EVERYthing there is to know about your idol? ** Check it out: http://www.fanpagesindex.com/ From owner-state-threads@oss.sgi.com Mon Sep 25 16:25:59 2000 Received: by oss.sgi.com id ; Mon, 25 Sep 2000 16:25:49 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:43595 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 25 Sep 2000 16:25:15 -0700 Received: from trudge.engr.sgi.com (trudge.engr.sgi.com [163.154.38.51]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA11324 for ; Mon, 25 Sep 2000 16:17:01 -0700 (PDT) mail_from (mja@trudge.engr.sgi.com) Received: (from mja@localhost) by trudge.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id QAA63320; Mon, 25 Sep 2000 16:22:26 -0700 (PDT) From: mja@trudge.engr.sgi.com (Mike Abbott) Message-Id: <200009252322.QAA63320@trudge.engr.sgi.com> Subject: Re: per-thread global variables To: matthijs@helena.tux.nu (Matthijs Sypkens Smit) Date: Mon, 25 Sep 2000 16:22:26 -0700 (PDT) Cc: state-threads@oss.sgi.com In-Reply-To: <00092600080101.06092@helena> from "Matthijs Sypkens Smit" at Sep 26, 2000 12:08:01 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: > I'm currently working on a project to create a client-server implementation > of a differential equation analysis tool. > [...] Sounds like you want to use thread-specific data. Put all the data for each connection in a struct and store a pointer to it as TSD. -- Michael J. Abbott mja@sgi.com http://reality.sgi.com/mja/ From owner-state-threads@oss.sgi.com Thu Sep 28 19:37:29 2000 Received: by oss.sgi.com id ; Thu, 28 Sep 2000 19:37:20 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:38003 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 28 Sep 2000 19:36:57 -0700 Received: from metrostar.engr.sgi.com (metrostar.engr.sgi.com [163.154.38.57]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id TAA23899 for ; Thu, 28 Sep 2000 19:29:13 -0700 (PDT) mail_from (genes@metrostar.engr.sgi.com) Received: (from genes@localhost) by metrostar.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id TAA11216 for state-threads@oss.sgi.com; Thu, 28 Sep 2000 19:10:18 -0700 From: "Gene Shekhtman" Message-Id: <10009281910.ZM11214@metrostar.engr.sgi.com> Date: Thu, 28 Sep 2000 19:10:18 -0700 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: state-threads@oss.sgi.com Subject: ST 1.1-dev Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: The snapshot of the current ST source tree is now available as a development version (st-1.1-dev). Please see the ChangeLog.txt file for changes since version 1.0. There are no serious bug fixes (none reported), so if you are not interested in Linux IA-64 port or performance profiling on IRIX, you don't need to upgrade. http://oss.sgi.com/projects/state-threads/download/ As always, your contributions and comments are welcome. -- Gene Shekhtman genes@sgi.com Internet Systems Engineering 650-933-8676 Silicon Graphics, Inc. From owner-state-threads@oss.sgi.com Sat Nov 4 11:44:50 2000 Received: by oss.sgi.com id ; Sat, 4 Nov 2000 11:44:30 -0800 Received: from femail6.sdc1.sfba.home.com ([24.0.95.86]:36857 "EHLO femail6.sdc1.sfba.home.com") by oss.sgi.com with ESMTP id ; Sat, 4 Nov 2000 11:44:07 -0800 Received: from home.com ([24.11.49.110]) by femail6.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001104194407.ZACV2410.femail6.sdc1.sfba.home.com@home.com> for ; Sat, 4 Nov 2000 11:44:07 -0800 Message-ID: <3A046702.1E928441@home.com> Date: Sat, 04 Nov 2000 14:44:02 -0500 From: Danil Melomedman X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-test9 i586) X-Accept-Language: en, ru MIME-Version: 1.0 To: state-threads@oss.sgi.com Subject: Need examples for file I/O using st. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: Hi. Wonder if there are some code examples or snippets available to do scalable file i/o using state threads? Also something like reading a text file and counting characters in the most efficient manner possible would be great (POP3 servers and FTP servers do this all the time, but usually do it very slowly character by character). Thanks. From owner-state-threads@oss.sgi.com Mon Nov 13 17:42:13 2000 Received: by oss.sgi.com id ; Mon, 13 Nov 2000 17:42:04 -0800 Received: from femail7.sdc1.sfba.home.com ([24.0.95.87]:18568 "EHLO femail7.sdc1.sfba.home.com") by oss.sgi.com with ESMTP id ; Mon, 13 Nov 2000 17:41:40 -0800 Received: from home.com ([24.11.49.110]) by femail7.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001114014135.JNSW2350.femail7.sdc1.sfba.home.com@home.com> for ; Mon, 13 Nov 2000 17:41:35 -0800 Message-ID: <3A109841.94B84A45@home.com> Date: Mon, 13 Nov 2000 20:41:21 -0500 From: Danil Melomedman X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-test9 i586) X-Accept-Language: en, ru MIME-Version: 1.0 To: state-threads@oss.sgi.com Subject: Private Data Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: I am putting together a POP3 server. It allocates a structure per message, all those structures must be private. There's also an array of pointers to those structs (should also be private). What would be a good approach to use st_thread_setspecific() so that none of the structures are damaged? Do I need a key per malloced struct? I can see how one struct can easily be privatized, but can't imagine a good way to do it with many dynamically allocated structs. Help would be greately appreciated. Regards. -- Dan From owner-state-threads@oss.sgi.com Tue Nov 14 10:10:28 2000 Received: by oss.sgi.com id ; Tue, 14 Nov 2000 10:10:08 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:23375 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 14 Nov 2000 10:09:47 -0800 Received: from trudge.engr.sgi.com (trudge.engr.sgi.com [163.154.38.51]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA13181 for ; Tue, 14 Nov 2000 10:01:55 -0800 (PST) mail_from (mja@trudge.engr.sgi.com) Received: (from mja@localhost) by trudge.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id KAA10962 for state-threads@oss.sgi.com; Tue, 14 Nov 2000 10:07:46 -0800 (PST) From: mja@trudge.engr.sgi.com (Mike Abbott) Message-Id: <200011141807.KAA10962@trudge.engr.sgi.com> Subject: Re: Private Data To: state-threads@oss.sgi.com Date: Tue, 14 Nov 2000 10:07:46 -0800 (PST) In-Reply-To: <3A109841.94B84A45@home.com> from "Danil Melomedman" at Nov 13, 2000 08:41:21 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: > I am putting together a POP3 server. It allocates a structure per > message, all those structures must be private. There's also an array of > pointers to those structs (should also be private). What would be a good > approach to use st_thread_setspecific() so that none of the structures > are damaged? State threads share an address space so there's no way to protect one thread's "private" data from accidental or malicious damage by another thread. The only way to prevent such damage is to use separate address spaces which usually implies separate processes. However, this usually isn't necessary. > Do I need a key per malloced struct? Impractical. There are only 16 keys in the default distribution (ST_KEYS_MAX) so you'd quickly run out. Instead use just one key to store a pointer to a structure that contains all of the data (and/or pointers to additional data) for one thread. All the data is out there; each thread just needs a unique starting point for wading through it. -- Michael J. Abbott mja@sgi.com http://reality.sgi.com/mja/ From owner-state-threads@oss.sgi.com Fri Dec 22 16:35:13 2000 Received: by oss.sgi.com id ; Fri, 22 Dec 2000 16:35:03 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:46655 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 22 Dec 2000 16:34:48 -0800 Received: from metrostar.engr.sgi.com (metrostar.engr.sgi.com [163.154.38.57]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA01785 for ; Fri, 22 Dec 2000 16:33:58 -0800 (PST) mail_from (genes@metrostar.engr.sgi.com) Received: (from genes@localhost) by metrostar.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id QAA50641 for state-threads@oss.sgi.com; Fri, 22 Dec 2000 16:32:54 -0800 (PST) Date: Fri, 22 Dec 2000 16:32:54 -0800 (PST) From: genes@metrostar.engr.sgi.com (Gene Shekhtman) Message-Id: <10012221632.ZM50669@metrostar.engr.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: state-threads@oss.sgi.com Subject: Version 1.1 released Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: Hello everyone, ST 1.1 is now available on oss.sgi.com: http://oss.sgi.com/projects/state-threads/download/ Please see the ChangeLog.txt file for changes since version 1.0. As always, your contributions and comments are welcome. Have a Happy Holiday! -- Gene Shekhtman Internet Systems Engineering Silicon Graphics, Inc. From owner-state-threads@oss.sgi.com Sat Dec 23 10:10:23 2000 Received: by oss.sgi.com id ; Sat, 23 Dec 2000 10:10:03 -0800 Received: from femail9.sdc1.sfba.home.com ([24.0.95.89]:58545 "EHLO femail9.sdc1.sfba.home.com") by oss.sgi.com with ESMTP id ; Sat, 23 Dec 2000 10:09:43 -0800 Received: from [24.11.49.110] by femail9.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20001223180942.RSRL21435.femail9.sdc1.sfba.home.com@[24.11.49.110]> for ; Sat, 23 Dec 2000 10:09:42 -0800 Received: (nullmailer pid 2353 invoked by uid 1000); Sat, 23 Dec 2000 18:09:31 -0000 Date: Sat, 23 Dec 2000 13:09:31 -0500 From: Dan Melomedman To: state-threads@oss.sgi.com Subject: Different select/poll implementations Message-ID: <20001223130931.A2347@home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: This has probably slipped someone's mind before, but I still would like to ask if state-threads will also support more scalable implementations like Niels Provos' /dev/poll and FreeBSD's kqueues in the future? From owner-state-threads@oss.sgi.com Tue Jan 2 06:40:13 2001 Received: by oss.sgi.com id ; Tue, 2 Jan 2001 06:40:03 -0800 Received: from [206.138.37.235] ([206.138.37.235]:22803 "EHLO corpmail.level8.com") by oss.sgi.com with ESMTP id ; Tue, 2 Jan 2001 06:39:49 -0800 Received: from level8.com (slip-32-102-60-9.fl.us.prserv.net [32.102.60.9]) by corpmail.level8.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id ZXX1KF0R; Tue, 2 Jan 2001 09:40:02 -0500 Message-ID: <3A51EA17.8579D870@level8.com> Date: Tue, 02 Jan 2001 09:47:51 -0500 From: Gregory Nicholls X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 CC: state-threads@oss.sgi.com Subject: State threads on NT References: <200011141807.KAA10962@trudge.engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: unlisted-recipients:; (no To-header on input) Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: Hi all, If anyone is interested I have a hacked version of st1.0 that works on NT. I'm not in a position to supply this as a set of patches due to general incompetence with CVS et al. however if someone would like a copy to play with feel free to email me and I'll be happy to send you the code. Gregory Nicholls. From owner-state-threads@oss.sgi.com Mon Jan 8 18:13:49 2001 Received: by oss.sgi.com id ; Mon, 8 Jan 2001 18:13:39 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:47158 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 8 Jan 2001 18:13:31 -0800 Received: from metrostar.engr.sgi.com (metrostar.engr.sgi.com [163.154.38.57]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA01948 for ; Mon, 8 Jan 2001 18:22:15 -0800 (PST) mail_from (genes@metrostar.engr.sgi.com) Received: (from genes@localhost) by metrostar.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id SAA90924; Mon, 8 Jan 2001 18:11:39 -0800 (PST) Date: Mon, 8 Jan 2001 18:11:39 -0800 (PST) From: genes@metrostar.engr.sgi.com (Gene Shekhtman) Message-Id: <10101081811.ZM90903@metrostar.engr.sgi.com> In-Reply-To: "g.p.ciceri" "mailing list problems from libero.it" (Dec 28, 1:19am) References: <3A4A8702.1080401@acm.org> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: state-threads@oss.sgi.com Subject: Re: ST and dbms client libraries Cc: "g.p.ciceri" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: On Dec 28, 1:19am, g.p.ciceri wrote: > Subject: ST and dbms client libraries > > hi all, > I'd like to know what kind of interaction can exist between > state threads and a client dbms library (postgreSQL, in this case). > > Since I've read that ST must do socket IO > > [snip from docs] > >The library's main limitation: > > > > All I/O operations on sockets must use the State Thread library's > I/O functions >because only those functions > > perform thread scheduling and prevent the application's processes > from blocking. > > I suppose that there will be problems using DBMS client libraries (since > they DO socket IO); in particular a DBMS call can block the VP > (and all the underlying STs), following the general examples/server.c > server architecture. > > I'd like to know if there's some strategy to work around this > kind of problems (apart the straightforward but lenghty way to > re-implement the wire DBMS client/server comm. protocol using > STs instead the native solution). > > One can observes that perhaps STs are not the correct way to interact > with a DBMS, but the idea is to build a sort of DB proxy / TP monitor > and > so the EDSM architecture seems to be a good applicative model: any > remarks will be highly appreciated, as usual. > > Thanks for your time and Best Regards. > /gp You are right -- if DBMS client libraries do socket I/O, they need to be re-written to use ST I/O functions (it may be relatively easy since all you need is to replace read()/write()/send()/recv()/etc. with corresponding ST functions). This is a general problem -- external libraries should conform to the core server architecture. E.g., if the core server uses POSIX threads, all libraries must be thread-safe and if the core server is ST-based, all libraries must use ST socket I/O. There is a way, however, to extend the functionality of the core server by using separate "helper" processes. The core server may use ST functions to communicate over some form of IPC (pipes, socketpairs) with "helper" processes which in turn use external DBMS libraries. That makes sense only if not all transactions require DB communications. Zeus web server uses this approach -- static requests (and some ISAPI plug-ins) are served by the core server but plug-ins that may use external libraries incompatible with Zeus' EDSM architecture are executed by "helper" processes outside the core server. Regards, Gene -- Gene Shekhtman Internet Systems Engineering Silicon Graphics, Inc. From owner-state-threads@oss.sgi.com Tue Jan 9 16:45:57 2001 Received: by oss.sgi.com id ; Tue, 9 Jan 2001 16:45:47 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:28198 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 9 Jan 2001 16:45:27 -0800 Received: from metrostar.engr.sgi.com (metrostar.engr.sgi.com [163.154.38.57]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA00178 for ; Tue, 9 Jan 2001 16:54:11 -0800 (PST) mail_from (genes@metrostar.engr.sgi.com) Received: (from genes@localhost) by metrostar.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id QAA93823 for state-threads@oss.sgi.com; Tue, 9 Jan 2001 16:43:35 -0800 (PST) Date: Tue, 9 Jan 2001 16:43:35 -0800 (PST) From: genes@metrostar.engr.sgi.com (Gene Shekhtman) Message-Id: <10101091643.ZM93624@metrostar.engr.sgi.com> In-Reply-To: Dan Melomedman "Different select/poll implementations" (Dec 23, 1:09pm) References: <20001223130931.A2347@home.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: state-threads@oss.sgi.com Subject: Re: Different select/poll implementations Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: On Dec 23, 1:09pm, Dan Melomedman wrote: > Subject: Different select/poll implementations > > This has probably slipped someone's mind before, > but I still would like to ask > if state-threads will also support more scalable implementations like > Niels Provos' /dev/poll and FreeBSD's kqueues in the future? I think that the performance impact of different poll() implementations is somewhat overrated by kernel people. In the ST architecture poll() or select() is only called in the idle state when the run queue is exhausted and there is nothing more to do. In the "busy" case when we have many active file descriptors, the run queue becomes very long (many runnable threads) and poll()/select() calls are relatively infrequent (even less frequent than once per second, as it was during our SPECweb benchmarking tests). In this situation reducing the polling time even to zero won't improve the throughput by much. In the "slow" case when we have many file descriptors but only few of them are active, the polling time is the same as in the "busy" case but the run queue is short and poll()/select() calls _are_ frequent. The system should be mostly idle, however, because only few threads are active. Thus response times are still much better than in the "busy" case above. All of the above is true unless the polling time is much greater than the request service time (which is not the case for realistic applications). Your comments/feedback are always welcome. Regards, Gene -- Gene Shekhtman Internet Systems Engineering Silicon Graphics, Inc. From owner-state-threads@oss.sgi.com Thu Jan 11 15:47:03 2001 Received: by oss.sgi.com id ; Thu, 11 Jan 2001 15:46:44 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:47888 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 11 Jan 2001 15:46:34 -0800 Received: from metrostar.engr.sgi.com (metrostar.engr.sgi.com [163.154.38.57]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA09643 for ; Thu, 11 Jan 2001 15:55:21 -0800 (PST) mail_from (genes@metrostar.engr.sgi.com) Received: (from genes@localhost) by metrostar.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA99684 for state-threads@oss.sgi.com; Thu, 11 Jan 2001 15:44:44 -0800 (PST) Date: Thu, 11 Jan 2001 15:44:44 -0800 (PST) From: genes@metrostar.engr.sgi.com (Gene Shekhtman) Message-Id: <10101111544.ZM99735@metrostar.engr.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: state-threads@oss.sgi.com Subject: Re: State threads on NT Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: State Threads' NT port is now available on oss.sgi.com: http://oss.sgi.com/projects/state-threads/download/ Thanks to Gregory Nicholls who owns the port. -- Gene Shekhtman Internet Systems Engineering Silicon Graphics, Inc. From owner-state-threads@oss.sgi.com Fri Feb 2 11:51:29 2001 Received: by oss.sgi.com id ; Fri, 2 Feb 2001 11:51:09 -0800 Received: from [206.138.37.235] ([206.138.37.235]:35853 "EHLO corpmail.level8.com") by oss.sgi.com with ESMTP id ; Fri, 2 Feb 2001 11:50:46 -0800 Received: from level8.com (slip166-72-68-79.fl.us.prserv.net [166.72.68.79]) by corpmail.level8.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id DQ56G9Y6; Fri, 2 Feb 2001 14:50:44 -0500 Message-ID: <3A7B11CD.CC5A2018@level8.com> Date: Fri, 02 Feb 2001 15:00:13 -0500 From: Gregory Nicholls X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: state-threads@oss.sgi.com Subject: advice on interrupt handling please Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: Hiya, I'm putting together an SSL server using state-threads. For reasons I won't go into here I need to be able to interrupt the threads using st_interrupt(). My problem is that the interrupt could be delivered to my SSL code at almost anytime, including during an SSL negotiation. I'd like to be able to 'defer' the receipt of the interrupt while I'm in the middle of a series of 'must complete' data transfers. I can't readily see a way of doing this with the current stlib so I'm thinking of adding suspend/resume logic so I can defer the interrupt until I'm able to handle it. My question is, has anyone else run into this issue and if so, how did you deal with it ?? Thanks for any clues, Greg. From owner-state-threads@oss.sgi.com Fri Feb 2 16:03:31 2001 Received: by oss.sgi.com id ; Fri, 2 Feb 2001 16:03:22 -0800 Received: from D8FA50FE.ptr.dia.nextlink.net ([216.250.80.254]:4613 "EHLO NS.abeona.com") by oss.sgi.com with ESMTP id ; Fri, 2 Feb 2001 16:02:57 -0800 Received: from abeona.com (IDENT:gsh@concord [192.168.1.56]) by NS.abeona.com (8.9.3/8.9.3) with ESMTP id PAA02145; Fri, 2 Feb 2001 15:57:43 -0800 Message-ID: <3A7B4938.6983AF3D@abeona.com> Date: Fri, 02 Feb 2001 15:56:41 -0800 From: Gene Shekhtman Organization: Abeona Networks, Inc. X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Gregory Nicholls CC: state-threads@oss.sgi.com Subject: Re: advice on interrupt handling please References: <3A7B11CD.CC5A2018@level8.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: Gregory Nicholls wrote: > Hiya, > I'm putting together an SSL server using state-threads. For reasons > I won't go into here I need to be able to interrupt the threads using > st_interrupt(). My problem is that the interrupt could be delivered to > my SSL code at almost anytime, including during an SSL negotiation. I'd > like to be able to 'defer' the receipt of the interrupt while I'm in the > middle of a series of 'must complete' data transfers. > I can't readily see a way of doing this with the current stlib so > I'm thinking of adding suspend/resume logic so I can defer the interrupt > until I'm able to handle it. > My question is, has anyone else run into this issue and if so, how > did you deal with it ?? Ah! That's a common problem. Actually, you don't need to modify the ST library to solve it. All you need is two boolean flags in your per session/connection information to correctly maintain the state, e.g. int dont_interrupt; /* Set this flag to 1 while in "must complete" state */ int interrupted; /* Set this flag to 1 if session was interrupted */ Both flags are initialized to 0. In the code fragment below I assume some sort of "session" data structure where all session/connection information is kept, but you can also store these flags in a per-thread private data. void interrupt_session(session_t *s) { /* Check if session is in the non-interruptible state */ if (!s->dont_interrupt) st_interrupt(s->thread); /* Set the flag */ s->interrupted = 1; } Now the processing code: .... .... /* First, check if this session was interrupted */ if (s->interrupted) { /* Handle interrupt: return error code, abort session/connection/thread, etc. */ .... } /* Set "don't interrupt" flag before entering "must complete" section */ s->dont_interrupt = 1; /* Enter critical "must complete" section */ .... .... /* Done with critical section. Reset "don't interrupt" flag */ s->dont_interrupt = 0; /* Now, check again if this session was interrupted while in critical section */ if (s->interrupted) { /* Handle interrupt: return error code, abort session/connection/thread, etc. */ .... } /* Continue non-critical processing */ .... Note that all of the above can be used safely with State Threads because they are non-concurrent and non-preemptive and there is no race condition. You cannot do it with POSIX threads or any other "true" threads. With ST you can always maintain the state with the right number of flags :) --Gene From owner-state-threads@oss.sgi.com Mon Feb 5 06:30:55 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 06:30:45 -0800 Received: from [206.138.37.235] ([206.138.37.235]:18184 "EHLO corpmail.level8.com") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 06:30:31 -0800 Received: from level8.com (slip-129-37-30-49.fl.us.prserv.net [129.37.30.49]) by corpmail.level8.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id DQ56HC6A; Mon, 5 Feb 2001 09:30:31 -0500 Message-ID: <3A7EBB3F.483F3E6B@level8.com> Date: Mon, 05 Feb 2001 09:39:59 -0500 From: Gregory Nicholls X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: state-threads@oss.sgi.com Subject: Re: advice on interrupt handling please References: <3A7B11CD.CC5A2018@level8.com> <3A7B4938.6983AF3D@abeona.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: Hiya, Yeah that'll work, thanks. It's close to what I was planning on adding into stlib. The main reason I thought it would be good to have in the base code is that this is where every thread comes out to play. I do have session context in my system however the function that issues the interrupt doesn't (yet) have access to this context. How tough would it be to add the state flags to the stlib thread struct and hold the state there ??? An st_defer_interrupt(st_thread_t tid, bool yes) would probably be enough to switch it on or off. The idea would be to deliver an EINTR on response to st_defer_interrupt(tid, FALSE) if an interrupt had been generated during the defer period. Comments ?? G. Gene Shekhtman wrote: > Gregory Nicholls wrote: > > > Hiya, > > I'm putting together an SSL server using state-threads. For reasons > > I won't go into here I need to be able to interrupt the threads using > > st_interrupt(). My problem is that the interrupt could be delivered to > > my SSL code at almost anytime, including during an SSL negotiation. I'd > > like to be able to 'defer' the receipt of the interrupt while I'm in the > > middle of a series of 'must complete' data transfers. > > I can't readily see a way of doing this with the current stlib so > > I'm thinking of adding suspend/resume logic so I can defer the interrupt > > until I'm able to handle it. > > My question is, has anyone else run into this issue and if so, how > > did you deal with it ?? > > Ah! That's a common problem. Actually, you don't need to modify > the ST library to solve it. All you need is two boolean flags in your > per session/connection information to correctly maintain the state, e.g. > > int dont_interrupt; /* Set this flag to 1 while in "must complete" state */ > > int interrupted; /* Set this flag to 1 if session was interrupted */ > > Both flags are initialized to 0. > > In the code fragment below I assume some sort of "session" data structure > where all session/connection information is kept, but you can also store > these flags in a per-thread private data. > > void interrupt_session(session_t *s) > { > /* Check if session is in the non-interruptible state */ > if (!s->dont_interrupt) > st_interrupt(s->thread); > /* Set the flag */ > s->interrupted = 1; > } > > Now the processing code: > .... > .... > /* First, check if this session was interrupted */ > if (s->interrupted) { > /* Handle interrupt: return error code, abort session/connection/thread, > etc. */ > .... > } > > /* Set "don't interrupt" flag before entering "must complete" section */ > s->dont_interrupt = 1; > /* Enter critical "must complete" section */ > .... > .... > /* Done with critical section. Reset "don't interrupt" flag */ > s->dont_interrupt = 0; > > /* Now, check again if this session was interrupted while in critical > section */ > if (s->interrupted) { > /* Handle interrupt: return error code, abort session/connection/thread, > etc. */ > .... > } > > /* Continue non-critical processing */ > .... > > Note that all of the above can be used safely with State Threads because > they are non-concurrent and non-preemptive and there is no race condition. > You cannot do it with POSIX threads or any other "true" threads. > With ST you can always maintain the state with the right number of flags :) > > --Gene From owner-state-threads@oss.sgi.com Mon Feb 5 07:00:54 2001 Received: by oss.sgi.com id ; Mon, 5 Feb 2001 07:00:45 -0800 Received: from [206.138.37.235] ([206.138.37.235]:39949 "EHLO corpmail.level8.com") by oss.sgi.com with ESMTP id ; Mon, 5 Feb 2001 07:00:24 -0800 Received: from level8.com (slip-129-37-30-49.fl.us.prserv.net [129.37.30.49]) by corpmail.level8.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id DQ56HC86; Mon, 5 Feb 2001 09:45:13 -0500 Message-ID: <3A7EBEB0.EEB0B5BB@level8.com> Date: Mon, 05 Feb 2001 09:54:41 -0500 From: Gregory Nicholls X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: state-threads@oss.sgi.com Subject: Re: advice on interrupt handling please References: <3A7B11CD.CC5A2018@level8.com> <3A7B4938.6983AF3D@abeona.com> <3A7EBB3F.483F3E6B@level8.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: Forget what I just wrote. Blame it on a late night. I'll go away and think it through properly. G. Gregory Nicholls wrote: > Hiya, > Yeah that'll work, thanks. It's close to what I was planning on adding into > stlib. The main reason I thought it would be good to have in the base code is > that this is where every thread comes out to play. I do have session context in > my system however the function that issues the interrupt doesn't (yet) have > access to this context. > How tough would it be to add the state flags to the stlib thread struct and > hold the state there ??? > An st_defer_interrupt(st_thread_t tid, bool yes) would probably be enough to > switch it on or off. The idea would be to deliver an EINTR on response to > st_defer_interrupt(tid, FALSE) if an interrupt had been generated > during the defer period. > Comments ?? > G. > > Gene Shekhtman wrote: > > > Gregory Nicholls wrote: > > > > > Hiya, > > > I'm putting together an SSL server using state-threads. For reasons > > > I won't go into here I need to be able to interrupt the threads using > > > st_interrupt(). My problem is that the interrupt could be delivered to > > > my SSL code at almost anytime, including during an SSL negotiation. I'd > > > like to be able to 'defer' the receipt of the interrupt while I'm in the > > > middle of a series of 'must complete' data transfers. > > > I can't readily see a way of doing this with the current stlib so > > > I'm thinking of adding suspend/resume logic so I can defer the interrupt > > > until I'm able to handle it. > > > My question is, has anyone else run into this issue and if so, how > > > did you deal with it ?? > > > > Ah! That's a common problem. Actually, you don't need to modify > > the ST library to solve it. All you need is two boolean flags in your > > per session/connection information to correctly maintain the state, e.g. > > > > int dont_interrupt; /* Set this flag to 1 while in "must complete" state */ > > > > int interrupted; /* Set this flag to 1 if session was interrupted */ > > > > Both flags are initialized to 0. > > > > In the code fragment below I assume some sort of "session" data structure > > where all session/connection information is kept, but you can also store > > these flags in a per-thread private data. > > > > void interrupt_session(session_t *s) > > { > > /* Check if session is in the non-interruptible state */ > > if (!s->dont_interrupt) > > st_interrupt(s->thread); > > /* Set the flag */ > > s->interrupted = 1; > > } > > > > Now the processing code: > > .... > > .... > > /* First, check if this session was interrupted */ > > if (s->interrupted) { > > /* Handle interrupt: return error code, abort session/connection/thread, > > etc. */ > > .... > > } > > > > /* Set "don't interrupt" flag before entering "must complete" section */ > > s->dont_interrupt = 1; > > /* Enter critical "must complete" section */ > > .... > > .... > > /* Done with critical section. Reset "don't interrupt" flag */ > > s->dont_interrupt = 0; > > > > /* Now, check again if this session was interrupted while in critical > > section */ > > if (s->interrupted) { > > /* Handle interrupt: return error code, abort session/connection/thread, > > etc. */ > > .... > > } > > > > /* Continue non-critical processing */ > > .... > > > > Note that all of the above can be used safely with State Threads because > > they are non-concurrent and non-preemptive and there is no race condition. > > You cannot do it with POSIX threads or any other "true" threads. > > With ST you can always maintain the state with the right number of flags :) > > > > --Gene From owner-state-threads@oss.sgi.com Wed Feb 28 02:56:08 2001 Received: by oss.sgi.com id ; Wed, 28 Feb 2001 02:55:49 -0800 Received: from lan194.nice.imaginet.fr ([195.68.21.194]:53772 "EHLO nevrax.com") by oss.sgi.com with ESMTP id ; Wed, 28 Feb 2001 02:55:39 -0800 Received: from vianneyl (fw.localdomain [192.168.254.254]) by nevrax.com (8.9.3/8.9.3) with SMTP id MAA12591 for ; Wed, 28 Feb 2001 12:02:01 +0100 Message-ID: <00d201c0a175$513160d0$0901a8c0@vianneyl> From: "Vianney Lecroart" To: Subject: some questions Date: Wed, 28 Feb 2001 11:58:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: Hello, First of all, your library seems very very cool.Wwe (nevrax) work on an massively multi online role player game and we would like to use state thread to manage our few thousands simulaneous player connections per process. we can't create one thread per user so we would like to create one state thread per user (who many state thread can manage without too much cpu lost). Our game is under GPL licence and your library is under NPL and NPL isn t compatible with GPL so normally we can t use it. but in all your source files, there a part that say that we can replace the NPL licence with another licence. so is it possible to use state threads lib in you GPL project by remplacing the NPL licence by the GPL one? Another question: is it possible to create a poll of real thread (around 100) and each real thread manage around 50 state thread? can we mix system threads and state threads without problem? Thank you for your help our project web site is: www.nevrax.org Vianney Lecroart --- lead network programmer / nevrax.com icq#: 6870415 homepage: http://ace.planet-d.net www.geekcode.com: GCS/E d- s+++: a-- C+++$ UL++ P- L+++>+$ E+>- W++ N+ o? K- w++$ O- M- V- PS- PE? Y PGP t 5? X+ R- tv++ b- DI D+ G e++ h+ r-- y? From owner-state-threads@oss.sgi.com Thu Mar 1 12:39:36 2001 Received: by oss.sgi.com id ; Thu, 1 Mar 2001 12:39:25 -0800 Received: from D8FA50FE.ptr.dia.nextlink.net ([216.250.80.254]:6660 "EHLO NS.abeona.com") by oss.sgi.com with ESMTP id ; Thu, 1 Mar 2001 12:39:19 -0800 Received: from abeona.com (IDENT:gsh@concord [192.168.1.56]) by NS.abeona.com (8.9.3/8.9.3) with ESMTP id MAA01101; Thu, 1 Mar 2001 12:38:49 -0800 Message-ID: <3A9EB2DB.E71031DE@abeona.com> Date: Thu, 01 Mar 2001 12:36:43 -0800 From: Gene Shekhtman Organization: Abeona Networks, Inc. X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Vianney Lecroart CC: state-threads@oss.sgi.com Subject: Re: some questions References: <00d201c0a175$513160d0$0901a8c0@vianneyl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: > Another question: is it possible to create a poll of real thread (around > 100) and each real thread manage around 50 state thread? > can we mix system threads and state threads without problem? I can answer this one. No, you can't mix system (POSIX-, solaris-, linux-, etc.) threads with state threads. The ST library was designed to use process as the only "kernel execution vehicle" (many-to-one model). To take advantage of multiple CPUs you should create multiple processes. Why do you need such a large pool of "real" threads? Do you do a lot of disk I/O? Regards, Gene From owner-state-threads@oss.sgi.com Mon Mar 5 15:21:03 2001 Received: by oss.sgi.com id ; Mon, 5 Mar 2001 15:20:53 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:12604 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Mon, 5 Mar 2001 15:20:33 -0800 Received: from trudge.engr.sgi.com ([163.154.38.51]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA00177 for ; Mon, 5 Mar 2001 15:20:31 -0800 (PST) mail_from (mja@trudge.engr.sgi.com) Received: (from mja@localhost) by trudge.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA11786 for state-threads@oss.sgi.com; Mon, 5 Mar 2001 15:18:34 -0800 (PST) From: mja@trudge.engr.sgi.com (Mike Abbott) Message-Id: <200103052318.PAA11786@trudge.engr.sgi.com> Subject: State threads relicensed To: state-threads@oss.sgi.com Date: Mon, 5 Mar 2001 15:18:34 -0800 (PST) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk Return-Path: SGI has relicensed its open source State Threads library. Formerly under the Netscape Public License (NPL), version 1.1 of the library is now dual licensed under the Mozilla Public License (MPL) version 1.1 or the GNU General Public License (GPL) version 2 or later. http://oss.sgi.com/projects/state-threads/ -- Michael J. Abbott mja@sgi.com http://reality.sgi.com/mja/ From owner-state-threads@oss.sgi.com Sun May 20 12:12:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4KJCED21299 for state-threads-outgoing; Sun, 20 May 2001 12:12:14 -0700 Received: from femail9.sdc1.sfba.home.com (femail9.sdc1.sfba.home.com [24.0.95.89]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4KJCEF21296 for ; Sun, 20 May 2001 12:12:14 -0700 Received: from [24.11.49.110] by femail9.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010520191207.NEAB17191.femail9.sdc1.sfba.home.com@[24.11.49.110]> for ; Sun, 20 May 2001 12:12:07 -0700 Received: (nullmailer pid 334 invoked by uid 1000); Sun, 20 May 2001 19:07:22 -0000 Date: Sun, 20 May 2001 15:07:22 -0400 From: Dan Melomedman To: state-threads@oss.sgi.com Subject: IPC model Message-ID: <20010520150722.A326@home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-state-threads@oss.sgi.com Precedence: bulk I am writing a POP3 server that must have an ability to do LDAP authentication (search a database in remote server). I am going to be using OpenLDAP 2.0.x libraries for now. Does this mean that a process could be potentially blocked, even though OpenLDAP does have asynchronous search functions? If so, what would be an efficient and state-thread safe method of IPC, if I split the server into two (one being the POP3 server, the other being help processes that will accomplish LDAP authentication and return a response to a thread via IPC). I would also have the helper processes eventually do disk read I/O for the server. One way of doing this could be a FIFO or a local Unix socket (DGRAM or STREAM)? I can see that doing this with SysV message queues would be the easiest, but I do not want to support SysV message queues problems. I cannot see how this could be accomplished with UDP sockets because the helper process could grab its own response instead of getting it to the thread that requested it. What about synchronization problems, response ordering, request ordering? Any examples out there? Any help would be greately appreciated. P.S. I e-mailed Vivek S. Pai to access their source, but so far got no response back. From owner-state-threads@oss.sgi.com Mon May 21 15:55:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4LMtRa23133 for state-threads-outgoing; Mon, 21 May 2001 15:55:27 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LMtQF23130 for ; Mon, 21 May 2001 15:55:26 -0700 Received: from trudge.engr.sgi.com ([163.154.38.51]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA04836 for ; Mon, 21 May 2001 15:55:26 -0700 (PDT) mail_from (mja@trudge.engr.sgi.com) Received: (from mja@localhost) by trudge.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA10411; Mon, 21 May 2001 15:53:09 -0700 (PDT) From: mja@trudge.engr.sgi.com (Mike Abbott) Message-Id: <200105212253.PAA10411@trudge.engr.sgi.com> Subject: Re: IPC model To: dmelomed@home.com (Dan Melomedman) Date: Mon, 21 May 2001 15:53:09 -0700 (PDT) Cc: state-threads@oss.sgi.com In-Reply-To: <20010520150722.A326@home.com> from "Dan Melomedman" at May 20, 2001 03:07:22 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk > I am going to be using OpenLDAP 2.0.x libraries for now. > Does this mean that a process could be potentially blocked, even though > OpenLDAP does have asynchronous search functions? That depends on whether OpenLDAP ever issues any blocking I/O calls, whether to disk, network, or a pipe. > If so, what would be > an efficient and state-thread safe method of IPC, if I split the server > into two (one being the POP3 server, the other being help processes that > will accomplish LDAP authentication and return a response to a thread > via IPC). I would also have the helper processes eventually do disk read > I/O for the server. Use the State Thread Library's I/O functions over a pipe or TCP socket pair. See http://oss.sgi.com/projects/state-threads/docs/notes.html#disk If you port OpenLDAP to use the State Thread Library's I/O functions instead of native functions (st_write instead of write on sockets) it can run in the same process. If it does disk I/O though the asymmetric architecture performs better. -- Michael J. Abbott mja@sgi.com www.repbot.org/mike From owner-state-threads@oss.sgi.com Mon May 21 20:06:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f4M36Dx27599 for state-threads-outgoing; Mon, 21 May 2001 20:06:13 -0700 Received: from femail8.sdc1.sfba.home.com (femail8.sdc1.sfba.home.com [24.0.95.88]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4M36CF27596 for ; Mon, 21 May 2001 20:06:12 -0700 Received: from [24.11.49.110] by femail8.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010522030611.FZVZ578.femail8.sdc1.sfba.home.com@[24.11.49.110]> for ; Mon, 21 May 2001 20:06:11 -0700 Received: (nullmailer pid 444 invoked by uid 1000); Tue, 22 May 2001 03:01:24 -0000 Date: Mon, 21 May 2001 23:01:24 -0400 From: Dan Melomedman To: state-threads@oss.sgi.com Subject: Re: IPC model Message-ID: <20010521230124.A424@home.com> References: <20010520150722.A326@home.com> <200105212253.PAA10411@trudge.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105212253.PAA10411@trudge.engr.sgi.com>; from mja@trudge.engr.sgi.com on Mon, May 21, 2001 at 03:53:09PM -0700 Sender: owner-state-threads@oss.sgi.com Precedence: bulk On Mon, May 21, 2001 at 03:53:09PM -0700, Mike Abbott generated a stream of 1s and 0s: > > I am going to be using OpenLDAP 2.0.x libraries for now. > > Does this mean that a process could be potentially blocked, even though > > OpenLDAP does have asynchronous search functions? > > That depends on whether OpenLDAP ever issues any blocking I/O calls, > whether to disk, network, or a pipe. > Yes, OpenLDAP uses blocking I/O, network only. > > If so, what would be > > an efficient and state-thread safe method of IPC, if I split the server > > into two (one being the POP3 server, the other being help processes that > > will accomplish LDAP authentication and return a response to a thread > > via IPC). I would also have the helper processes eventually do disk read > > I/O for the server. > > Use the State Thread Library's I/O functions over a pipe or TCP socket > pair. See > http://oss.sgi.com/projects/state-threads/docs/notes.html#disk > > If you port OpenLDAP to use the State Thread Library's I/O functions > instead of native functions (st_write instead of write on sockets) it > can run in the same process. If it does disk I/O though the asymmetric > architecture performs better. > -- > Michael J. Abbott mja@sgi.com www.repbot.org/mike Porting would probably be too much of effort to justify what I am trying to accomplish it looks like quite a bit of code. Besides I don't think anyone else is interested in OpenLDAP supporting state threads :(. Do I have to use st_ functions in the help processes also (forked from main daemon processeses), OR can I have the help processes run separarately as a second daemon communicating over a named pipe or a BSD domain socket by any chance? From owner-state-threads@oss.sgi.com Mon Jun 11 03:03:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5BA3RU29514 for state-threads-outgoing; Mon, 11 Jun 2001 03:03:27 -0700 Received: from sockratte.schell.de (polz.de [195.20.238.74]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5BA3PV29509 for ; Mon, 11 Jun 2001 03:03:25 -0700 Received: (qmail 26817 invoked from network); 11 Jun 2001 10:03:23 -0000 Received: from unknown (HELO rossini.schumann.cx) (217.81.234.82) by polz.de with SMTP; 11 Jun 2001 10:03:23 -0000 Received: from localhost (localhost [127.0.0.1]) by rossini.schumann.cx (Postfix) with ESMTP id 6F3C05E007 for ; Mon, 11 Jun 2001 12:02:55 +0200 (MEST) Date: Mon, 11 Jun 2001 12:02:55 +0200 (MEST) From: Sascha Schumann X-X-Sender: To: Subject: [PATCH] improve _st_vp_idle() speed Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463809536-27401629-992253775=:368" Sender: owner-state-threads@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1463809536-27401629-992253775=:368 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, applications which use large IO queues spend a lot of time poll()ing fds. The attached patch tries to minimize the impact of the O(n) interface by introducing a couple of changes to _st_vp_idle(): 1. The manual iteration over all fds to copy them has been replaced by a memcpy per IO-queue. 2. The function of the iteration over the final pollfd array has been changed to only check for active fds and avoid any memory writes. When an active fd is found, it skips all further checks for that particular IO queue and memcpy's the complete fd set. This patch has been extensively tested under real world conditions (the application uses about 10K sockets and frequently st_poll()s 5K of them). - Sascha Experience IRCG http://schumann.cx/ http://schumann.cx/ircg ---1463809536-27401629-992253775=:368 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="st-fast-poll.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="st-fast-poll.patch" ZGlmZiAtdXIgc3QtMS4xL3NjaGVkLmMgc3QtMS4xLXAvc2NoZWQuYw0KLS0t IHN0LTEuMS9zY2hlZC5jCVRodSBEZWMgMjEgMDQ6MTc6MTkgMjAwMA0KKysr IHN0LTEuMS1wL3NjaGVkLmMJTW9uIEp1biAxMSAwODo0Njo1NiAyMDAxDQpA QCAtNDY3LDEyICs0NjcsOSBAQA0KICAgLyogR2F0aGVyIGFsbCBkZXNjcmlw dG9ycyBpbnRvIG9uZSBhcnJheSAqLw0KICAgZm9yIChxID0gX1NUX0lPUS5u ZXh0OyBxICE9ICZfU1RfSU9ROyBxID0gcS0+bmV4dCkgew0KICAgICBwcSA9 IF9TVF9QT0xMUVVFVUVfUFRSKHEpOw0KLSAgICBlcGRzID0gcHEtPnBkcyAr IHBxLT5ucGRzOw0KIA0KLSAgICBmb3IgKHBkcyA9IHBxLT5wZHM7IHBkcyA8 IGVwZHM7IHBkcysrLCBwb2xsZmRzKyspIHsNCi0gICAgICBTVF9BU1NFUlQo cG9sbGZkcyA8IF9TVF9QT0xMRkRTICsgX1NUX1BPTExGRFNfU0laRSk7DQot ICAgICAgKnBvbGxmZHMgPSAqcGRzOw0KLSAgICB9DQorICAgIG1lbWNweShw b2xsZmRzLCBwcS0+cGRzLCBzaXplb2Yoc3RydWN0IHBvbGxmZCkgKiBwcS0+ bnBkcyk7DQorICAgIHBvbGxmZHMgKz0gcHEtPm5wZHM7DQogICB9DQogDQog ICBpZiAoU1RfQ0xJU1RfSVNfRU1QVFkoJl9TVF9TTEVFUFEpKSB7DQpAQCAt NDkwLDE4ICs0ODcsMTggQEANCiAgICAgcG9sbGZkcyA9IF9TVF9QT0xMRkRT Ow0KICAgICBmb3IgKHEgPSBfU1RfSU9RLm5leHQ7IHEgIT0gJl9TVF9JT1E7 IHEgPSBxLT5uZXh0KSB7DQogICAgICAgcHEgPSBfU1RfUE9MTFFVRVVFX1BU UihxKTsNCi0gICAgICBlcGRzID0gcHEtPnBkcyArIHBxLT5ucGRzOw0KKyAg ICAgIGVwZHMgPSBwb2xsZmRzICsgcHEtPm5wZHM7DQogICAgICAgbm90aWZ5 ID0gMDsNCiANCi0gICAgICBmb3IgKHBkcyA9IHBxLT5wZHM7IHBkcyA8IGVw ZHM7IHBkcysrLCBwb2xsZmRzKyspIHsNCi0JU1RfQVNTRVJUKHBvbGxmZHMg PCBfU1RfUE9MTEZEUyArIF9TVF9QT0xMRkRTX1NJWkUpOw0KLQlTVF9BU1NF UlQocG9sbGZkcy0+ZmQgPT0gcGRzLT5mZCk7DQotCXBkcy0+cmV2ZW50cyA9 IHBvbGxmZHMtPnJldmVudHM7DQotCS8qIE5lZ2F0aXZlIGZkJ3MgYXJlIGln bm9yZWQgYnkgcG9sbCgpICovDQotCWlmIChwZHMtPmZkID49IDAgJiYgcGRz LT5yZXZlbnRzKQ0KLQkgIG5vdGlmeSA9IDE7DQotICAgICAgfQ0KKyAgICAg IGZvciAocGRzID0gcG9sbGZkczsgcGRzIDwgZXBkczsgcGRzKyspDQorICAg ICAgICAvKiBOZWdhdGl2ZSBmZCdzIGFyZSBpZ25vcmVkIGJ5IHBvbGwoKSAq Lw0KKyAgICAgICAgaWYgKHBkcy0+cmV2ZW50cyAmJiBwZHMtPmZkID49IDAp IHsNCisgICAgICAgICAgbm90aWZ5ID0gMTsNCisgICAgICAgICAgYnJlYWs7 DQorICAgICAgICB9DQorICAgICAgDQogICAgICAgaWYgKG5vdGlmeSkgew0K KyAgICAgICAgbWVtY3B5KHBxLT5wZHMsIHBvbGxmZHMsIHNpemVvZihzdHJ1 Y3QgcG9sbGZkKSAqIHBxLT5ucGRzKTsNCiAgICAgICAgIFNUX1JFTU9WRV9M SU5LKCZwcS0+bGlua3MpOw0KICAgICAgICAgcHEtPm9uX2lvcSA9IDA7DQog DQpAQCAtNTEzLDYgKzUxMCw3IEBADQogCV9TVF9PU0ZEX0NOVCAtPSBwcS0+ bnBkczsNCiAJU1RfQVNTRVJUKF9TVF9PU0ZEX0NOVCA+PSAwKTsNCiAgICAg ICB9DQorICAgICAgcG9sbGZkcyArPSBwcS0+bnBkczsNCiAgICAgfQ0KICAg fQ0KIH0NCg== ---1463809536-27401629-992253775=:368-- From owner-state-threads@oss.sgi.com Thu Jun 21 13:16:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5LKGN320303 for state-threads-outgoing; Thu, 21 Jun 2001 13:16:23 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5LKGMV20300 for ; Thu, 21 Jun 2001 13:16:22 -0700 Received: from trudge.engr.sgi.com (trudge.engr.sgi.com [163.154.38.51]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA08348 for ; Thu, 21 Jun 2001 13:16:52 -0700 (PDT) mail_from (mja@trudge.engr.sgi.com) Received: (from mja@localhost) by trudge.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id NAA15184 for state-threads@oss.sgi.com; Thu, 21 Jun 2001 13:15:05 -0700 (PDT) From: mja@trudge.engr.sgi.com (Mike Abbott) Message-Id: <200106212015.NAA15184@trudge.engr.sgi.com> Subject: State Threads version 1.2 To: state-threads@oss.sgi.com Date: Thu, 21 Jun 2001 13:15:05 -0700 (PDT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk Version 1.2 of the State Threads library is now available. Please see the ChangeLog.txt file for changes since version 1.1. As always, your contributions and comments are welcome. http://oss.sgi.com/projects/state-threads/ -- Michael J. Abbott mja@sgi.com www.repbot.org/mike From owner-state-threads@oss.sgi.com Mon Jun 25 20:21:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5Q3L9Z08138 for state-threads-outgoing; Mon, 25 Jun 2001 20:21:09 -0700 Received: from femail9.sdc1.sfba.home.com (femail9.sdc1.sfba.home.com [24.0.95.89]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5Q3L7V08135 for ; Mon, 25 Jun 2001 20:21:07 -0700 Received: from [24.11.49.110] by femail9.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010626013528.IZPI23553.femail9.sdc1.sfba.home.com@[24.11.49.110]> for ; Mon, 25 Jun 2001 18:35:28 -0700 Received: (nullmailer pid 331 invoked by uid 1000); Tue, 26 Jun 2001 01:29:42 -0000 Date: Mon, 25 Jun 2001 21:29:42 -0400 From: Dan Melomedman To: state-threads@oss.sgi.com Subject: Alternative I/O multiplexing Message-ID: <20010625212941.A315@home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.18i Sender: owner-state-threads@oss.sgi.com Precedence: bulk So poll() does take quite a bit of time with large descriptor sets in state-threads according to Sacha's message. Any benchmarks to show the difference under Linux 2.4.x or FreeBSD with patch? It is also known that both select() and poll() are very slow under Linux with large decriptor sets. This brings me back to the question I asked a while a go: would it make sense to add alternative polling support to st library such as /dev/poll under Linux, or a whole different method such as kqueues in FreeBSD/OpenBSD? As I recall from a thread awhile ago, the answer was it would not. From owner-state-threads@oss.sgi.com Mon Jul 16 03:07:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GA7Ju17343 for state-threads-outgoing; Mon, 16 Jul 2001 03:07:19 -0700 Received: from wiprom2mx2.wipro.com (wiprom2mx2.wipro.com [203.197.164.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GA7FV17336 for ; Mon, 16 Jul 2001 03:07:16 -0700 Received: from m2vwall3.wipro.com ([192.168.2.23]) by wiprom2mx2.wipro.com (8.9.3/8.9.3) with SMTP id QAA26298 for ; Mon, 16 Jul 2001 16:46:11 +0530 Received: from darkstar ([192.168.191.219]) by lvlmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GGK9UN00.2E4 for ; Mon, 16 Jul 2001 15:45:59 +0530 Message-ID: <000701c10de0$24b372a0$dbbfa8c0@IISDOMAIN.WEBSECURE> From: "Parag Warudkar" To: Subject: Using with LDAP Date: Mon, 16 Jul 2001 15:44:48 +0530 Organization: Wipro Technologies MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-state-threads@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, We are planning to use state threads library in our server application which serves login requests. The UserID/Passwords are stored in LDAP. So the Server needs to do network io with LDAP via the Netscape directory SDK for C, which has asynchronous functions. The state threads documentation states that only state thread i/o routines should be used. Is there any way to use CSDK async functions with state-threads? TIA, Parag Food for thought ----------------- Eat, drink and be merry, for tomorrow they might make it illegal. "Just how much can I get away with and still go to heaven?" --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" The Information contained and transmitted by this E-MAIL is proprietary to Wipro Limited and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Company. If you are not the intended recipient, an agent of the intended recipient or a person responsible for delivering the information to the named recipient, you are notified that any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have received this communication in error, please delete this mail & notify us immediately at mailadmin@wipro.com --------------InterScan_NT_MIME_Boundary-- From owner-state-threads@oss.sgi.com Mon Jul 16 12:04:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GJ4cR19038 for state-threads-outgoing; Mon, 16 Jul 2001 12:04:38 -0700 Received: from femail8.sdc1.sfba.home.com (femail8.sdc1.sfba.home.com [24.0.95.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GJ4bV19035 for ; Mon, 16 Jul 2001 12:04:37 -0700 Received: from [24.11.49.110] by femail8.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010716190437.SGTT7782.femail8.sdc1.sfba.home.com@[24.11.49.110]> for ; Mon, 16 Jul 2001 12:04:37 -0700 Received: (nullmailer pid 297 invoked by uid 1000); Mon, 16 Jul 2001 18:58:31 -0000 Date: Mon, 16 Jul 2001 14:58:31 -0400 From: Dan Melomedman To: state-threads@oss.sgi.com Subject: Re: Using with LDAP Message-ID: <20010716145831.D231@home.com> References: <000701c10de0$24b372a0$dbbfa8c0@IISDOMAIN.WEBSECURE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000701c10de0$24b372a0$dbbfa8c0@IISDOMAIN.WEBSECURE> User-Agent: Mutt/1.3.18i Sender: owner-state-threads@oss.sgi.com Precedence: bulk You'll have to use helper processes for LDAP library functions. You can communicate between your main server process and your helper functions via socketpair(). Those asynchronous LDAP functions are AFAIK use blocking I/O. The reason you need helper processes it to avoid blocking your server process and therefore all its threads as per state threads documentation. The only problem I see with helper processes is the high overhead of fork(). It seems like you'll be forking a process per LDAP search, which is very expensive, and IMHO diminishes the original purpose of a high performance multithreaded server. I am guessing you could have your helper processes pre-forked(), spawning additional helpers as needed, but this still wastes resources. Does anyone have a better suggestion? Would it be possible to run two separate servers one being the main server, and the other being the LDAP helper server which would do IPC via a local UNIX socket for the purpose of avoiding fork()? How would we differentiate between requests from different state threads? The LDAP search server could be multithreaded using alternate threading libraries like pthreads or GnuPth. > We are planning to use state threads library in our server application > which serves login requests. The UserID/Passwords are stored in LDAP. So the > Server needs to do network io with LDAP via the Netscape directory SDK for > C, which has asynchronous functions. The state threads documentation states > that only state thread i/o routines should be used. Is there any way to use From owner-state-threads@oss.sgi.com Mon Jul 16 14:38:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GLcZN32531 for state-threads-outgoing; Mon, 16 Jul 2001 14:38:35 -0700 Received: from mail.abeona.com ([209.81.58.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GLcYV32528 for ; Mon, 16 Jul 2001 14:38:34 -0700 Received: from abeona.com (IDENT:gsh@concord [192.168.1.56]) by mail.abeona.com (8.9.3/8.9.3) with ESMTP id OAA10859; Mon, 16 Jul 2001 14:35:45 -0700 Message-ID: <3B535EDE.C9E3B861@abeona.com> Date: Mon, 16 Jul 2001 14:38:38 -0700 From: Gene Shekhtman Organization: Abeona Networks, Inc. X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: state-threads@oss.sgi.com, parag.warudkar@Wipro.com CC: Dan Melomedman Subject: Re: Using with LDAP References: <000701c10de0$24b372a0$dbbfa8c0@IISDOMAIN.WEBSECURE> <20010716145831.D231@home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk Dan Melomedman wrote: > > Does anyone have a better suggestion? Would it be possible to run two > separate servers one being the main server, and the other being the LDAP > helper server which would do IPC via a local UNIX socket for the purpose > of avoiding fork()? How would we differentiate between requests from > different state threads? The LDAP search server could be multithreaded > using alternate threading libraries like pthreads or GnuPth. > > > We are planning to use state threads library in our server application > > which serves login requests. The UserID/Passwords are stored in LDAP. So the > > Server needs to do network io with LDAP via the Netscape directory SDK for > > C, which has asynchronous functions. The state threads documentation states > > that only state thread i/o routines should be used. Is there any way to use I'd suggest two things: 1. Use very simple LDAP "helper" server that listens to a local (UNIX domain) socket and accept()s connections from the "main" server which calls ST functions (st_connect(), st_write(), st_read()). The "helper" server may just pre-fork a fixed (and always constant) number of processes that use Netscape directory SDK. Of course, you'll be able to have only as many simultaneous LDAP queries as the number of processes in the "helper" server. 2. Cache UserID/Passwords in the "main" server. Only if a UserID hasn't been found in the local cache, you communicate with the "helper" server to do a LDAP query. Regards, Gene From owner-state-threads@oss.sgi.com Mon Jul 16 15:20:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GMKTR01502 for state-threads-outgoing; Mon, 16 Jul 2001 15:20:29 -0700 Received: from femail10.sdc1.sfba.home.com (femail10.sdc1.sfba.home.com [24.0.95.106]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GMKSV01499 for ; Mon, 16 Jul 2001 15:20:28 -0700 Received: from [24.11.49.110] by femail10.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010716222022.BSPV20244.femail10.sdc1.sfba.home.com@[24.11.49.110]> for ; Mon, 16 Jul 2001 15:20:22 -0700 Received: (nullmailer pid 362 invoked by uid 1000); Mon, 16 Jul 2001 22:14:17 -0000 Date: Mon, 16 Jul 2001 18:14:17 -0400 From: Dan Melomedman To: state-threads@oss.sgi.com Subject: Re: Using with LDAP Message-ID: <20010716181417.A352@home.com> Mail-Followup-To: state-threads@oss.sgi.com References: <000701c10de0$24b372a0$dbbfa8c0@IISDOMAIN.WEBSECURE> <20010716145831.D231@home.com> <3B535EDE.C9E3B861@abeona.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B535EDE.C9E3B861@abeona.com> User-Agent: Mutt/1.3.18i Sender: owner-state-threads@oss.sgi.com Precedence: bulk On Mon, Jul 16, 2001 at 02:38:38PM -0700, Gene Shekhtman wrote the following: > 1. Use very simple LDAP "helper" server that listens to a local (UNIX domain) > socket and accept()s connections from the "main" server which calls ST > functions (st_connect(), st_write(), st_read()). The "helper" server may > just pre-fork a fixed (and always constant) number of processes that use > Netscape directory SDK. Of course, you'll be able to have only as many > simultaneous LDAP queries as the number of processes in the "helper" server. This should work very well for usual server loads where most people have authenticated themselves and most data is sitting in cache. But if the LDAP server replica is running on the local machine to avoid network I/O, this cache could be rendered useless since LDAP servers maintain their own cache. Also, even if the LDAP server is not local to the state-threaded server, what happens when hundreds or even thousands of LDAP queries are needed when they're not in cache? Preforking too many processes would IMHO create too much kernel overhead, while having those processes in deficit would create delays. Is there a better way? Also, what would be an efficient model for disk I/O helpers? From owner-state-threads@oss.sgi.com Mon Jul 16 17:16:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6H0GJW03929 for state-threads-outgoing; Mon, 16 Jul 2001 17:16:19 -0700 Received: from mail.abeona.com ([209.81.58.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6H0GIV03926 for ; Mon, 16 Jul 2001 17:16:18 -0700 Received: from abeona.com (IDENT:gsh@concord [192.168.1.56]) by mail.abeona.com (8.9.3/8.9.3) with ESMTP id RAA13995 for ; Mon, 16 Jul 2001 17:13:33 -0700 Message-ID: <3B5383DB.1DD8D030@abeona.com> Date: Mon, 16 Jul 2001 17:16:27 -0700 From: Gene Shekhtman Organization: Abeona Networks, Inc. X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: state-threads@oss.sgi.com Subject: Re: Using with LDAP References: <000701c10de0$24b372a0$dbbfa8c0@IISDOMAIN.WEBSECURE> <20010716145831.D231@home.com> <3B535EDE.C9E3B861@abeona.com> <20010716181417.A352@home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk Dan Melomedman wrote: > This should work very well for usual server loads where most people have > authenticated themselves and most data is sitting in cache. But if the > LDAP server replica is running on the local machine to avoid network I/O, > this cache could be rendered useless since LDAP servers maintain their own > cache. Local "in-process" cache is never useless :) It's just a different level of caching (just like bigger L2 CPU cache doesn't make L1 cache useless). > Also, even if the LDAP server is not local to the state-threaded > server, what happens when hundreds or even thousands of LDAP queries are > needed when they're not in cache? Preforking too many processes would > IMHO create too much kernel overhead, while having those processes in > deficit would create delays. I had in mind about 10 processes or so. If a LDAP query takes 20 ms, you'll be able to handle 500 queries per second. > Also, what would be an efficient model for disk I/O helpers? The Flash web server used disk I/O helpers for disk-bound workloads . I think the source code is available free of charge for non-commerial use. From owner-state-threads@oss.sgi.com Mon Jul 16 18:21:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6H1L2Y04981 for state-threads-outgoing; Mon, 16 Jul 2001 18:21:02 -0700 Received: from femail9.sdc1.sfba.home.com (femail9.sdc1.sfba.home.com [24.0.95.89]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6H1L1V04978 for ; Mon, 16 Jul 2001 18:21:01 -0700 Received: from [24.11.49.110] by femail9.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010717012027.FPIT2119.femail9.sdc1.sfba.home.com@[24.11.49.110]> for ; Mon, 16 Jul 2001 18:20:27 -0700 Received: (nullmailer pid 402 invoked by uid 1000); Tue, 17 Jul 2001 01:14:21 -0000 Date: Mon, 16 Jul 2001 21:14:21 -0400 From: Dan Melomedman To: state-threads@oss.sgi.com Subject: Re: Using with LDAP Message-ID: <20010716211421.A380@home.com> Mail-Followup-To: state-threads@oss.sgi.com References: <000701c10de0$24b372a0$dbbfa8c0@IISDOMAIN.WEBSECURE> <20010716145831.D231@home.com> <3B535EDE.C9E3B861@abeona.com> <20010716181417.A352@home.com> <3B5383DB.1DD8D030@abeona.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B5383DB.1DD8D030@abeona.com> User-Agent: Mutt/1.3.18i Sender: owner-state-threads@oss.sgi.com Precedence: bulk On Mon, Jul 16, 2001 at 05:16:27PM -0700, Gene Shekhtman wrote the following: > > Local "in-process" cache is never useless :) It's just a different level > of caching (just like bigger L2 CPU cache doesn't make L1 cache useless). > What I meant is it would be waste of RAM, though I understand there would be a performance gain. > > Also, what would be an efficient model for disk I/O helpers? > > The Flash web server used disk I/O helpers for disk-bound workloads > . I think the source code is > available free of charge for non-commerial use. I remember sending e-mail to Vivek about acquiring the source code, but never received a reply; I am not interested in selling any resulting software, but would love to take a look at the source. From owner-state-threads@oss.sgi.com Mon Jul 30 14:14:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6ULEZs12716 for state-threads-outgoing; Mon, 30 Jul 2001 14:14:35 -0700 Received: from vortex.undoo.com (vortex.undoo.com [209.19.65.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6ULEYV12713 for ; Mon, 30 Jul 2001 14:14:34 -0700 Received: from vortex.undoo.com (vortex.undoo.com [192.168.100.3]) by vortex.undoo.com (8.11.3/8.11.3) with ESMTP id f6ULEVZ06733 for ; Mon, 30 Jul 2001 14:14:31 -0700 (PDT) Date: Mon, 30 Jul 2001 14:14:31 -0700 (PDT) From: Claude Johnson X-Sender: cjohnson@vortex.undoo.com To: state-threads@oss.sgi.com Subject: Porting from POSIX threads to State Threads Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-state-threads@oss.sgi.com Precedence: bulk Alright, my basic question is what are the gotchas in making this move? I couldn't find anything in the archives about experiences or "good to knows" in making the move from POSIX threads to ST. I'm guessing the list would be fairly extensive. So if someone can run down the major gotchas, that would be helpful, in the sense of what are major differences between Pthreads and State Threads. Is such a port even possible? The following words, from http://www.mozilla.org/projects/nspr/reference/html/printro.html, are somewhat ominous: "NSPR does not provide a platform for porting existing code. It must be used from the beginning of a software project." If this applies to ST as well, can someone explain please? TIA! Claude Johnson Network Scientist Avamar Technologies 949.743.5145 Vox 949.743.5190 Fax www.avamar.com From owner-state-threads@oss.sgi.com Mon Jul 30 14:52:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6ULqrA13457 for state-threads-outgoing; Mon, 30 Jul 2001 14:52:53 -0700 Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6ULqpV13453 for ; Mon, 30 Jul 2001 14:52:51 -0700 Received: from acm.org (151.33.123.62) by smtp1.libero.it (5.5.025) id 3AE980E7014DF3E5 for state-threads@oss.sgi.com; Mon, 30 Jul 2001 23:52:45 +0200 Message-ID: <3B65D745.1FD302BD@acm.org> Date: Mon, 30 Jul 2001 23:53:09 +0200 From: "g.p.ciceri" Organization: swanLabs X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en, it MIME-Version: 1.0 To: state-threads@oss.sgi.com Subject: a plea to have some "helper" application sample along with the ST distribution. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk Hello all, following the mailing list discussions, it seems to me the major issue in building ST-enabled applications is still the handling of non ST-controlled operations, like performing disk I/O, query LDAP servers and/or DBMS, legacy network libraries, questions like these. The standard way to handle this issues is to build some "helper" application, connected to the ST-enabled one via some IPC mechanism like pipe(2) or socketpair(2), but unfortunately the suggested sample (quoting from a past discussion): >The Flash web server used disk I/O helpers for disk-bound workloads >. I think the source code is >available free of charge for non-commerial use. Is no longer available (at least, the author neither answers emails, nor releases the code). May I ask someone to provide a working sample of such a technique ??? For example, in the ST distribution there is the "server" sample: it should be nice to extend this sample with an "helper" app, given as reference. Any help/remark will be highly appreciated. Thanks for your patience, and best regards. /gp -- Discussion: How do you feel about Open Source firms making millions through public offerings? "I wish these companies were making the same millions without distributing any non-free, user-subjugating software." -- Richard Stallman "We're so forward that sometimes we reach ourself." -- g.p. "It is amazing how much you can achieve when you don't have to do the real work yourself." -- Joe Celko Gian Paolo Ciceri Via B.Diotti 45 - 20153 Milano MI ITALY CTO @ Louise mobile : ++39 347 4106213 : ++39 348 3658272 eMail : gp.ciceri@acm.org : gp.ciceri@louise.it webSite: http://www.louise.it ICQ # : 94620118 From owner-state-threads@oss.sgi.com Mon Jul 30 16:18:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6UNIX915173 for state-threads-outgoing; Mon, 30 Jul 2001 16:18:33 -0700 Received: from femail8.sdc1.sfba.home.com (femail8.sdc1.sfba.home.com [24.0.95.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6UNIWV15170 for ; Mon, 30 Jul 2001 16:18:32 -0700 Received: from [24.11.49.110] by femail8.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010730231827.ODHF5578.femail8.sdc1.sfba.home.com@[24.11.49.110]> for ; Mon, 30 Jul 2001 16:18:27 -0700 Received: (nullmailer pid 321 invoked by uid 1000); Mon, 30 Jul 2001 23:12:21 -0000 Date: Mon, 30 Jul 2001 19:12:21 -0400 From: Dan Melomedman To: state-threads@oss.sgi.com Subject: Re: a plea to have some "helper" application sample along with the ST distribution. Message-ID: <20010730191221.A307@home.com> Mail-Followup-To: state-threads@oss.sgi.com References: <3B65D745.1FD302BD@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B65D745.1FD302BD@acm.org> User-Agent: Mutt/1.3.18i Sender: owner-state-threads@oss.sgi.com Precedence: bulk Although an example would be great, it should not be too difficult to do it yourself. It's your usual IPC. For example a helper process can prefork several children that all listen on a UNIX domain socket. The server writes to the socket, and reads responses. Also what would be even better is a small LDAP client library done with ST. From owner-state-threads@oss.sgi.com Mon Jul 30 16:25:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6UNPaG15303 for state-threads-outgoing; Mon, 30 Jul 2001 16:25:36 -0700 Received: from femail4.sdc1.sfba.home.com (femail4.sdc1.sfba.home.com [24.0.95.84]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6UNPZV15300 for ; Mon, 30 Jul 2001 16:25:35 -0700 Received: from [24.11.49.110] by femail4.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010730232525.QCZO28538.femail4.sdc1.sfba.home.com@[24.11.49.110]> for ; Mon, 30 Jul 2001 16:25:25 -0700 Received: (nullmailer pid 328 invoked by uid 1000); Mon, 30 Jul 2001 23:19:19 -0000 Date: Mon, 30 Jul 2001 19:19:19 -0400 From: Dan Melomedman To: state-threads@oss.sgi.com Subject: Re: Porting from POSIX threads to State Threads Message-ID: <20010730191919.B307@home.com> Mail-Followup-To: state-threads@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i Sender: owner-state-threads@oss.sgi.com Precedence: bulk On Mon, Jul 30, 2001 at 02:14:31PM -0700, Claude Johnson wrote the following: > Alright, my basic question is what are the gotchas in > making this move? > > I couldn't find anything in the archives about experiences > or "good to knows" in making the move from POSIX threads > to ST. I'm guessing the list would be fairly extensive. > So if someone can run down the major gotchas, that would > be helpful, in the sense of what are major differences > between Pthreads and State Threads. If your thread blocks in ST, then your process blocks. Because of this, all network and disk I/O calls that are not implemented with ST library should either be converted to use ST, or should be used in an external process. Usually you do not need mutexes or thread safety like in most Pthread libraries in ST. From owner-state-threads@oss.sgi.com Tue Jul 31 02:11:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6V9BTk12273 for state-threads-outgoing; Tue, 31 Jul 2001 02:11:29 -0700 Received: from vortex.undoo.com (vortex.undoo.com [209.19.65.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6V9BRV12266 for ; Tue, 31 Jul 2001 02:11:27 -0700 Received: from vortex.undoo.com (vortex.undoo.com [192.168.100.3]) by vortex.undoo.com (8.11.3/8.11.3) with ESMTP id f6V9BLZ09453; Tue, 31 Jul 2001 02:11:21 -0700 (PDT) Date: Tue, 31 Jul 2001 02:11:21 -0700 (PDT) From: Claude Johnson X-Sender: cjohnson@vortex.undoo.com To: Dan Melomedman cc: state-threads@oss.sgi.com Subject: Re: Porting from POSIX threads to State Threads In-Reply-To: <20010730191919.B307@home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-state-threads@oss.sgi.com Precedence: bulk Okay, cool. What about differences in the libraries themselves? For example, the Pthread library has a pthread_attr_t type. What is the closest equivalent in the ST library? Is it even possible to control STs with that much granularity? NOTE: I am not a programmer but doing some investigation, so feel free to correct me if I say something that doesn't make sense. Example: The pthread_attr_t type. Since it doesn't appear that any similar device exists in ST, what solutions have been arrived at by those who have converted from Pthreads to ST? These are the kind of issues that concern me when I look at the code I'm working with and read the ST docs. On Mon, 30 Jul 2001, Dan Melomedman wrote: [*]On Mon, Jul 30, 2001 at 02:14:31PM -0700, Claude Johnson wrote the following: [*]> Alright, my basic question is what are the gotchas in [*]> making this move? [*]> [*]> I couldn't find anything in the archives about experiences [*]> or "good to knows" in making the move from POSIX threads [*]> to ST. I'm guessing the list would be fairly extensive. [*]> So if someone can run down the major gotchas, that would [*]> be helpful, in the sense of what are major differences [*]> between Pthreads and State Threads. [*] [*]If your thread blocks in ST, then your process blocks. Because of this, [*]all network and disk I/O calls that are not implemented with ST library [*]should either be converted to use ST, or should be used in an external [*]process. Usually you do not need mutexes or thread safety like in most [*]Pthread libraries in ST. [*] Claude Johnson Network Scientist Avamar Technologies 949.743.5145 Vox 949.743.5190 Fax www.avamar.com From owner-state-threads@oss.sgi.com Wed Aug 1 11:02:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71I2V609268 for state-threads-outgoing; Wed, 1 Aug 2001 11:02:31 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71I2UV09265 for ; Wed, 1 Aug 2001 11:02:30 -0700 Received: from trudge.engr.sgi.com (trudge.engr.sgi.com [163.154.38.51]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA07576 for ; Wed, 1 Aug 2001 11:02:14 -0700 (PDT) mail_from (mja@trudge.engr.sgi.com) Received: (from mja@localhost) by trudge.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA74496; Wed, 1 Aug 2001 11:00:58 -0700 (PDT) From: mja@trudge.engr.sgi.com (Mike Abbott) Message-Id: <200108011800.LAA74496@trudge.engr.sgi.com> Subject: Re: Porting from POSIX threads to State Threads To: cjohnson@avamar.com (Claude Johnson) Date: Wed, 1 Aug 2001 11:00:57 -0700 (PDT) Cc: state-threads@oss.sgi.com In-Reply-To: from "Claude Johnson" at Jul 31, 2001 02:11:21 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk Unless your pthreaded application is fairly simple I would imagine that converting it to state threads would probably require redesigning it from scratch. But since state threads are so much simpler to use than pthreads the mechanics of the switch should be pretty easy. You won't need mutexes any more. You won't have to bother with pthread_attr_t's and other barfage. You will need to ensure that every blocking I/O call uses its st_ wrapper. Personally, the hardest part about switching from pthreads to state threads was just wrapping my brain around how simple and elegant state threads are. No race conditions - they're impossible! Static variables are OK! No need for reentrant or thread-safe library functions! After years of painstakingly guarding data with mutexes it was hard to let go of them. Remember this mantra: If your state threaded application uses ANY mutexes, you're probably doing something wrong. All that being said, state threads are not appropriate for every application. Remember this mantra too: State threads are best for network data driven apps. Pthreads may work better for other kinds of jobs. -- Michael J. Abbott mja@sgi.com www.repbot.org/mike From owner-state-threads@oss.sgi.com Wed Aug 1 11:07:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f71I75A09380 for state-threads-outgoing; Wed, 1 Aug 2001 11:07:05 -0700 Received: from avamar.com (vortex.undoo.com [209.19.65.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f71I74V09377 for ; Wed, 1 Aug 2001 11:07:04 -0700 Received: from vortex.undoo.com (vortex.undoo.com [192.168.100.3]) by avamar.com (8.11.3/8.11.3) with ESMTP id f71I70L06794; Wed, 1 Aug 2001 11:07:00 -0700 (PDT) Date: Wed, 1 Aug 2001 11:07:00 -0700 (PDT) From: Claude Johnson X-Sender: cjohnson@vortex.undoo.com To: Mike Abbott cc: state-threads@oss.sgi.com Subject: Re: Porting from POSIX threads to State Threads In-Reply-To: <200108011800.LAA74496@trudge.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-state-threads@oss.sgi.com Precedence: bulk On Wed, 1 Aug 2001, Mike Abbott wrote: [*]Unless your pthreaded application is fairly simple I would imagine that [*]converting it to state threads would probably require redesigning it [*]from scratch. But since state threads are so much simpler to use than [*]pthreads the mechanics of the switch should be pretty easy. You won't [*]need mutexes any more. You won't have to bother with pthread_attr_t's [*]and other barfage. You will need to ensure that every blocking I/O call [*]uses its st_ wrapper. Hmm, I was just looking at how to deal with a pthread_detach call. And since I'm not a programmer, this could take a while 8-) There are lots of wrapper methods for the pthread functions (did I mention this app is in C++). So.... [Lossy compression] [*]All that being said, state threads are not appropriate for every [*]application. Remember this mantra too: State threads are best for [*]network data driven apps. Pthreads may work better for other kinds of [*]jobs. Yeah, this is a network server which is why ST looked compelling anyway. Thanx tho! [*]-- [*]Michael J. Abbott mja@sgi.com www.repbot.org/mike [*] Claude Johnson Network Scientist Avamar Technologies 949.743.5145 Vox 949.743.5190 Fax www.avamar.com From owner-state-threads@oss.sgi.com Mon Sep 24 02:39:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8O9d9726711 for state-threads-outgoing; Mon, 24 Sep 2001 02:39:09 -0700 Received: from mail.science.uva.nl (mail.science.uva.nl [146.50.4.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8O9d5e26708 for ; Mon, 24 Sep 2001 02:39:05 -0700 Received: from bergsee.bio.uva.nl [145.18.171.114] by mail.science.uva.nl with SMTP (sendmail 8.11.4/config 11.16). id f8O9cAo25213; Mon, 24 Sep 2001 11:38:10 +0200 (MEST) X-Organisation: Faculty of Science, University of Amsterdam, The Netherlands X-URL: http://www.science.uva.nl/ Content-Type: text/plain; charset="iso-8859-1" From: John Val To: state-threads@oss.sgi.com Date: Mon, 24 Sep 2001 11:33:26 +0200 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01092411323403.07213@bergsee.bio.uva.nl> Content-Transfer-Encoding: 8bit Subject: st_netfd_poll returns within the requested timeout with timed out error Sender: owner-state-threads@oss.sgi.com Precedence: bulk Dear state thread developpers/users, I am building an interactive client server application allowing for numerical analysis of dynamical dynamical systems. I am trying to use the state - thread library for this purpous. Currently I am running into problems with st_netfd_poll in as it looks st_write and st_read. During a computation I send the numerical results line after line to the client. Typically 1000 lines are send in one computation. On the client I noticed that some lines were not send correctly. I traked down the problem and noticed that if I write a line to the client such as st_write( clientfd, line, linelength, 1000000 ); I sometimes get a time out error. Reasonable since I give a timeout, but unreasonable while the timeout never amountts to the 1 second I request. It seems st_netfd_poll returns immediately!! Who can help me out? I am developping using linux 2.4.3 on a pentium III system. -- Dr. John Val Population Biology section Instituut voor Biodiversiteit en Ecosysteem Dynamica Faculteit der Natuurwetenschappen, Wiskunde en Informatica University of Amsterdam Kruislaan 320 1098SM Amsterdam Telephone: () 31 20 5257768 E-mail: val@science.uva.nl E-mail: j.val@hccnet.nl (personal) home: http://home.hccnet.nl/j.val From owner-state-threads@oss.sgi.com Tue Sep 25 05:03:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8PC3ep23413 for state-threads-outgoing; Tue, 25 Sep 2001 05:03:40 -0700 Received: from corpmail.level8.com ([207.124.41.30]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8PC3ZD23406 for ; Tue, 25 Sep 2001 05:03:35 -0700 Received: from level8.com (adsl-156-210-147.bct.bellsouth.net [66.156.210.147]) by corpmail.level8.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id TJQLM08J; Tue, 25 Sep 2001 08:04:59 -0400 Message-ID: <3BB0744B.DC97A6D3@level8.com> Date: Tue, 25 Sep 2001 08:10:51 -0400 From: Gregory Nicholls X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 CC: state-threads@oss.sgi.com Subject: Re: st_netfd_poll returns within the requested timeout with timed out error References: <01092411323403.07213@bergsee.bio.uva.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk Hi, I've had a bit of a look at the st_write() code and to me it looks bogus. If we complete a partial write and then timeout, we return -1. This doesn't give the caller any chance to update their data pointers and re-issue the call. In fact they have no idea whether data has been sent or not (the doc on st_write() confirms that this was the desired behaviour). I'd prefer that we return the number of bytes written and leave it to the caller to check whether the operation completed successfully. Comments ?? G. John Val wrote: > Dear state thread developpers/users, > > I am building an interactive client server application allowing for numerical > analysis of dynamical dynamical systems. I am trying to use the state - > thread library for this purpous. > Currently I am running into problems with st_netfd_poll in as it looks > st_write and st_read. > > During a computation I send the numerical results line after line to the > client. Typically 1000 lines are send in one computation. On the client I > noticed that some lines were not send correctly. I traked down the problem > and noticed that if I write a line to the client such as > > st_write( clientfd, line, linelength, 1000000 ); > > I sometimes get a time out error. Reasonable since I give a timeout, but > unreasonable while the timeout never amountts to the 1 second I request. > It seems st_netfd_poll returns immediately!! > > Who can help me out? > > I am developping using linux 2.4.3 on a pentium III system. > > -- > Dr. John Val > Population Biology section > Instituut voor Biodiversiteit en Ecosysteem Dynamica > Faculteit der Natuurwetenschappen, Wiskunde en Informatica > University of Amsterdam > Kruislaan 320 > 1098SM Amsterdam > > Telephone: () 31 20 5257768 > E-mail: val@science.uva.nl > E-mail: j.val@hccnet.nl (personal) > home: http://home.hccnet.nl/j.val From owner-state-threads@oss.sgi.com Tue Sep 25 12:05:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f8PJ5lK32537 for state-threads-outgoing; Tue, 25 Sep 2001 12:05:47 -0700 Received: from mail.abeona.com ([209.81.58.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f8PJ5iD32534 for ; Tue, 25 Sep 2001 12:05:44 -0700 Received: from abeona.com (IDENT:gsh@concord [192.168.1.56]) by mail.abeona.com (8.9.3/8.9.3) with ESMTP id MAA31135 for ; Tue, 25 Sep 2001 12:01:14 -0700 Message-ID: <3BB0D589.793C9033@abeona.com> Date: Tue, 25 Sep 2001 12:05:45 -0700 From: Gene Shekhtman Organization: Abeona Networks, Inc. X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: state-threads@oss.sgi.com Subject: Re: st_netfd_poll returns within the requested timeout with timed out error References: <01092411323403.07213@bergsee.bio.uva.nl> <3BB0744B.DC97A6D3@level8.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk Gregory Nicholls wrote: > Hi, > I've had a bit of a look at the st_write() code and to me it looks bogus. > If we complete a partial write and then timeout, we return -1. This doesn't give > the caller any chance to update their data pointers and re-issue the call. In > fact they have no idea whether data has been sent or not (the doc on st_write() > confirms that this was the desired behaviour). Indeed, it's a desired behavior. It's all or nothing. All ST's I/O functions have the same semantics: if connection was inactive for a specified amount of time, return -1. > I'd prefer that we return the > number of bytes written and leave it to the caller to check whether the operation > completed successfully. Nothing prevents you from writing your own custom function my_st_write() which does exactly what you want. All you need from ST is st_netfd_poll() which is a public function. --Gene From owner-state-threads@oss.sgi.com Tue Oct 2 11:32:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f92IWss21902 for state-threads-outgoing; Tue, 2 Oct 2001 11:32:54 -0700 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f92IWpD21899 for ; Tue, 2 Oct 2001 11:32:51 -0700 Received: from trudge.engr.sgi.com (trudge.engr.sgi.com [130.62.176.82]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f92IWkL03644 for ; Tue, 2 Oct 2001 11:32:46 -0700 Received: (from mja@localhost) by trudge.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA06881 for state-threads@oss.sgi.com; Tue, 2 Oct 2001 11:30:29 -0700 (PDT) From: mja@trudge.engr.sgi.com (Mike Abbott) Message-Id: <200110021830.LAA06881@trudge.engr.sgi.com> Subject: Resend: Re: st_netfd_poll ... To: state-threads@oss.sgi.com Date: Tue, 2 Oct 2001 11:30:28 -0700 (PDT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk [Resending. Originally sent 9/25 but it bounced!] > If we complete a partial write and then timeout, we return -1. This > doesn't give the caller any chance to update their data pointers and > re-issue the call. Except for timeouts, network I/O errors are usually unrecoverable, meaning that trying again won't help. I agree that when a network I/O operation times out after a partial success there ought to be a way to determine how much succeeded. As Gene suggested, write your own -- and then contribute it to the project for all to share. [Actually I have coded up a version of this in the interim but haven't tried it yet. Anyone want to test it for me?] However this is not John Val's original issue, which was that the timeout seems to trigger early. John, can you post a minimal program that exhibits the undesirable behavior so we can diagnose it? Can you make it happen with just a single state thread? Alternatively you could trace through the execution of the ST code yourself, watching for erroneous behavior, and ask for more specific help. -- Michael J. Abbott mja@sgi.com www.repbot.org/mike From owner-state-threads@oss.sgi.com Thu Oct 4 14:37:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f94LbYU23260 for state-threads-outgoing; Thu, 4 Oct 2001 14:37:34 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f94LbWD23257 for ; Thu, 4 Oct 2001 14:37:32 -0700 Received: from trudge.engr.sgi.com (trudge.engr.sgi.com [130.62.176.82]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f94LbQK17839 for ; Thu, 4 Oct 2001 14:37:26 -0700 Received: (from mja@localhost) by trudge.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id OAA24403 for state-threads@oss.sgi.com; Thu, 4 Oct 2001 14:35:08 -0700 (PDT) From: mja@trudge.engr.sgi.com (Mike Abbott) Message-Id: <200110042135.OAA24403@trudge.engr.sgi.com> Subject: Re: Code Re: Resend: Re: st_netfd_poll ... To: state-threads@oss.sgi.com Date: Thu, 4 Oct 2001 14:35:07 -0700 (PDT) In-Reply-To: <01100415052800.01075@bergsee.bio.uva.nl> from "John Val" at Oct 04, 2001 03:05:28 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk [John Val sent an example program to me and to the list, but the list rejected his too-large letter. This is my response to that letter, made public so others can contribute if desired.] John, thanks for the code. Got it to run. > Typically I get lines in errors like > [[04/Oct/2001:14:25:33] WARN: can't write line 1451 within, call took 3658 of > requested 10000 microseconds trying to write to 127.0.0.1: st_write: Timer > expired I see these errors too but the elapsed time is always greater than the 10000 usec timeout. Looks like your early timeouts are not a state-threads issue but an issue with the system on which you run the server. Can you try running the server on a different kind of system (different operating system, in particular) to see if the problem shows up there? Perhaps if you elaborate on the kind of system that exhibits the erroneous behavior someone will be able to say, "yeah, that O/S has timing problems, apply this patch...." -- Michael J. Abbott mja@sgi.com www.repbot.org/mike From owner-state-threads@oss.sgi.com Mon Oct 8 02:48:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f989mTx10181 for state-threads-outgoing; Mon, 8 Oct 2001 02:48:29 -0700 Received: from mail.science.uva.nl (mail.science.uva.nl [146.50.4.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f989mPD10178 for ; Mon, 8 Oct 2001 02:48:26 -0700 Received: from bergsee.bio.uva.nl [145.18.171.114] by mail.science.uva.nl with SMTP (sendmail 8.11.6/config 11.18). id f989kCc02916; Mon, 8 Oct 2001 11:46:12 +0200 (MEST) X-Organisation: Faculty of Science, University of Amsterdam, The Netherlands X-URL: http://www.science.uva.nl/ Content-Type: text/plain; charset="iso-8859-1" From: John Val To: mja@trudge.engr.sgi.com (Mike Abbott), state-threads@oss.sgi.com Subject: Re: Code Re: Resend: Re: st_netfd_poll ... Date: Mon, 8 Oct 2001 11:44:54 +0200 X-Mailer: KMail [version 1.2] References: <200110042135.OAA24403@trudge.engr.sgi.com> In-Reply-To: <200110042135.OAA24403@trudge.engr.sgi.com> MIME-Version: 1.0 Message-Id: <01100811445400.08009@bergsee.bio.uva.nl> Content-Transfer-Encoding: 8bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk Hi Mike Thanks for testing. Luckily you did not have the error. However I still have. I am running Linux-2.4.3 on a Dell inspiron/ 7500 with a 800 MHz processor. Any one else seeing this propblems? Thanks, John -- Dr. John Val Population Biology section Instituut voor Biodiversiteit en Ecosysteem Dynamica Faculteit der Natuurwetenschappen, Wiskunde en Informatica University of Amsterdam Kruislaan 320 1098SM Amsterdam Telephone: () 31 20 5257768 E-mail: val@science.uva.nl E-mail: j.val@hccnet.nl (personal) home: http://home.hccnet.nl/j.val From owner-state-threads@oss.sgi.com Wed Oct 10 14:38:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9ALcXb32379 for state-threads-outgoing; Wed, 10 Oct 2001 14:38:33 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9ALcVD32376 for ; Wed, 10 Oct 2001 14:38:31 -0700 Received: from trudge.engr.sgi.com (trudge.engr.sgi.com [130.62.176.82]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f9ALcQK25922 for ; Wed, 10 Oct 2001 14:38:26 -0700 Received: (from mja@localhost) by trudge.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id OAA32940 for state-threads@oss.sgi.com; Wed, 10 Oct 2001 14:36:03 -0700 (PDT) From: mja@trudge.engr.sgi.com (Mike Abbott) Message-Id: <200110102136.OAA32940@trudge.engr.sgi.com> Subject: 1.3a To: state-threads@oss.sgi.com Date: Wed, 10 Oct 2001 14:36:02 -0700 (PDT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk I wrote: > I agree that when a network I/O operation times out after a partial > success there ought to be a way to determine how much succeeded. > > [Actually I have coded up a version of this in the interim but haven't > tried it yet. Anyone want to test it for me?] This UNTESTED code, called version 1.3a (for alpha), is now available for download from: http://oss.sgi.com/projects/state-threads/download This does not address John Val's early-timeout issue, which we're still investigating. It only adds two new functions, st_read_resid and st_write_resid, to address the above deficiency. Read all about them in the included reference manual. I welcome all kinds of feedback. -- Michael J. Abbott mja@sgi.com www.repbot.org/mike From owner-state-threads@oss.sgi.com Mon Oct 15 16:05:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9FN5mY18426 for state-threads-outgoing; Mon, 15 Oct 2001 16:05:48 -0700 Received: from mail.abeona.com ([209.81.58.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9FN5dD18420 for ; Mon, 15 Oct 2001 16:05:44 -0700 Received: from abeona.com (IDENT:gsh@concord [192.168.1.56]) by mail.abeona.com (8.9.3/8.9.3) with ESMTP id PAA07733 for ; Mon, 15 Oct 2001 15:59:41 -0700 Message-ID: <3BCB6BC9.C5C0ADD5@abeona.com> Date: Mon, 15 Oct 2001 16:05:45 -0700 From: Gene Shekhtman Organization: Abeona Networks, Inc. X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: state-threads@oss.sgi.com Subject: Re: st_netfd_poll returns within the requested timeout with timed out error References: <01092411323403.07213@bergsee.bio.uva.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk John Val wrote: > During a computation I send the numerical results line after line to the > client. Typically 1000 lines are send in one computation. On the client I > noticed that some lines were not send correctly. I think that John's problem is caused by the fact that ST time resolution is actually a time interval between scheduling points. That time interval may be as large as 1 second in some situations (e.g., when a single thread does a lot of CPU-intensive work continuously without a context switch). Take a look at the _st_vp_check_clock() function in sched.c. The elapsed time is calculated as (now - _st_this_vp.last_clock) and then if (elapsed >= thread->sleep), thread is popped from the sleep queue. So, for example, if elapsed is 20ms and timeout is 10ms, the thread will wake up as soon as _st_vp_check_clock() is called. In John's case the specified I/O timeout of 10ms is less than the time interval between scheduling points. John's application issues about 1000 st_write()s before filling output socket buffer and going to select() with 10ms timeout. Linux select(2) man page says: timeout is an *upper* bound on the amount of time elapsed before select returns. If, for example, ~1000 st_writes took 8ms and select() timed out after 4ms, the elapsed time is 12ms (> 10ms) and st_write() returns with timeout error despite that it waited for only 4ms. I think that there is a misunderstanding around the whole timeout issue. In 99.9% of all cases I/O timeouts are used either for connection failure detection or to prevent a peer from holding idle connection for too long. So for most applications realistic I/O timeouts should usually be order of seconds. Also, I can't see any point in retrying after timeout happened. If someone wants to retry after timeout, why wouldn't he increase the timeout value to begin with? If application for some reason wants to know the number of bytes successfully transferred, it should use st_*_resid() functions Mike added in the 1.3a version. --Gene From owner-state-threads@oss.sgi.com Thu Oct 25 07:18:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PEI8I09256 for state-threads-outgoing; Thu, 25 Oct 2001 07:18:08 -0700 Received: from spelio.netli.lan ([194.58.47.40]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PEHwD09253 for ; Thu, 25 Oct 2001 07:17:58 -0700 Received: (from vlm@localhost) by spelio.netli.lan (8.11.3/8.11.1) id f9PEHo308203 for state-threads@oss.sgi.com; Thu, 25 Oct 2001 18:17:50 +0400 (MSD) (envelope-from vlm) Message-Id: <200110251417.f9PEHo308203@spelio.netli.lan> Subject: strange code To: state-threads@oss.sgi.com Date: Thu, 25 Oct 2001 18:17:49 +0400 (MSD) From: Lev Walkin X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-state-threads@oss.sgi.com Precedence: bulk Hi there, The sources (io.c) has the following function: === int st_connect(st_netfd_t *fd, struct sockaddr *addr, int addrlen, st_utime_t timeout) { int n, err = 0; while (connect(fd->osfd, addr, addrlen) < 0) { if (errno != EINTR) { if (errno != EINPROGRESS && (errno != EADDRINUSE || err == 0)) return -1; /* Wait until the socket becomes writable */ if (st_netfd_poll(fd, POLLOUT, timeout) < 0) return -1; /* Try to find out whether the connection setup succeeded or failed */ n = sizeof(int); if (getsockopt(fd->osfd, SOL_SOCKET, SO_ERROR, (char *)&err, (socklen_t *)&n) < 0) return -1; if (err) { errno = err; return -1; } break; } err = 1; } return 0; } === Can anybody explain the hidden meaning of err = 1 string? -- Lev Walkin vlm@netli.com From owner-state-threads@oss.sgi.com Thu Oct 25 16:19:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PNJ9l08306 for state-threads-outgoing; Thu, 25 Oct 2001 16:19:09 -0700 Received: from mail.abeona.com ([209.81.58.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PNJ4008302 for ; Thu, 25 Oct 2001 16:19:04 -0700 Received: from abeona.com (IDENT:gsh@concord [192.168.1.56]) by mail.abeona.com (8.9.3/8.9.3) with ESMTP id QAA06468; Thu, 25 Oct 2001 16:12:22 -0700 Message-ID: <3BD89DF2.60294384@abeona.com> Date: Thu, 25 Oct 2001 16:19:14 -0700 From: Gene Shekhtman Organization: Abeona Networks, Inc. X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Lev Walkin CC: state-threads@oss.sgi.com Subject: Re: strange code References: <200110251417.f9PEHo308203@spelio.netli.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk Lev Walkin wrote: > Hi there, > > The sources (io.c) has the following function: > > === > > int st_connect(st_netfd_t *fd, struct sockaddr *addr, int addrlen, > st_utime_t timeout) > { > int n, err = 0; > > while (connect(fd->osfd, addr, addrlen) < 0) { > if (errno != EINTR) { > if (errno != EINPROGRESS && (errno != EADDRINUSE || err == 0)) > return -1; > /* Wait until the socket becomes writable */ > if (st_netfd_poll(fd, POLLOUT, timeout) < 0) > return -1; > /* Try to find out whether the connection setup succeeded or failed */ > n = sizeof(int); > if (getsockopt(fd->osfd, SOL_SOCKET, SO_ERROR, (char *)&err, > (socklen_t *)&n) < 0) > return -1; > if (err) { > errno = err; > return -1; > } > break; > } > err = 1; > } > > return 0; > } > > === > > Can anybody explain the hidden meaning of > > err = 1 > > string? > Some platforms (e.g., IRIX 6.2, fixed in 6.5) have "peculiar" implementation of connect(2). On those platforms if connect(2) is interrupted (errno == EINTR) after socket was bound by the kernel, the second connect(2) attempt will fail with errno == EADDRINUSE. The code above ignores EADDRINUSE iff connect(2) was previously interrupted (the err flag was set). --Gene From owner-state-threads@oss.sgi.com Thu Oct 25 16:51:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f9PNpFZ09319 for state-threads-outgoing; Thu, 25 Oct 2001 16:51:15 -0700 Received: from mail.abeona.com ([209.81.58.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f9PNpC009316 for ; Thu, 25 Oct 2001 16:51:12 -0700 Received: from abeona.com (IDENT:gsh@concord [192.168.1.56]) by mail.abeona.com (8.9.3/8.9.3) with ESMTP id QAA07899; Thu, 25 Oct 2001 16:44:30 -0700 Message-ID: <3BD8A57A.EAFF2D24@abeona.com> Date: Thu, 25 Oct 2001 16:51:22 -0700 From: Gene Shekhtman Organization: Abeona Networks, Inc. X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Lev Walkin , state-threads@oss.sgi.com Subject: Re: strange code References: <200110251417.f9PEHo308203@spelio.netli.lan> <3BD89DF2.60294384@abeona.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-state-threads@oss.sgi.com Precedence: bulk Gene Shekhtman wrote: > > > > Can anybody explain the hidden meaning of > > > > err = 1 > > > > string? > > > > Some platforms (e.g., IRIX 6.2, fixed in 6.5) have "peculiar" > implementation of connect(2). On those platforms if connect(2) is > interrupted (errno == EINTR) after socket was bound by the kernel, > the second connect(2) attempt will fail with errno == EADDRINUSE. > > The code above ignores EADDRINUSE iff connect(2) was previously > interrupted (the err flag was set). > > --Gene I just found more details in the Rich Stevens' "UNIX Network Programming", Vol.1, 2nd edition, p. 413 ("Interrupted connect").