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