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: X-Orcpt: rfc822;state-threads-outgoing 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: X-Orcpt: rfc822;state-threads-outgoing 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: X-Orcpt: rfc822;state-threads-outgoing 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: X-Orcpt: rfc822;state-threads-outgoing 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.