Xref: utzoo comp.bugs.sys5:724 comp.unix.wizards:13686 Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!mailrus!ames!lll-lcc!unisoft!mtxinu!taniwha!paul From: paul@taniwha.UUCP (Paul Campbell) Newsgroups: comp.bugs.sys5,comp.unix.wizards Subject: Re: Surprising fact about STREAMS service modules Message-ID: <313@taniwha.UUCP> Date: 25 Dec 88 06:32:45 GMT References: <4385@hcr.UUCP> Reply-To: paul@taniwha.UUCP (Paul Campbell) Organization: Taniwha Systems Design, Oakland Lines: 42 In article <4385@hcr.UUCP> larry@hcr.UUCP (Larry Philps) writes: >Well, I just learned something about the STREAMS mechanism today. Since I >found it quite surprising, I thought I should mention it to the world before >some other poor sucker gets surprised also. >... >the spl at which the driver service modules are called. Silly me, I just >assumed that it would be at splstr. However, check out the following code >fragment from io/stream.c. I've always known about this but then I taught myself from the sources (no manuals aroud then ...). I've always assumed that there are only two things one can assume: - that no other service routine can be called while one is running (this should not apply in MP systems .... I always thought that multiple service routines could/would/should be running but none in the same stream [or its stream head code]). - that timeouts will not go off while service routines are being run (again this will probably not apply to MP systems). What you CAN'T assume is that put routines will not be called while a service routine is being run, one might be called from an interrupt service routine. Something else that's always assumed is that ISRs are all called at IPLs <= splstr (most systems I've worked with had splstr == 6 which is >= spltty). I have worked on one system where the device we were working with interrupted at > splstr (it had to - it had horrible real-time constraints). The games we had to play to make putq() safe were pretty bad! Paul PS: has anyone done a 'real' MP streams implementation? What sort of scheduling policies did you use? How did code have to change? Which of the above assumptions still apply? (This would probably make a good Usenix paper). -- Paul Campbell ..!{unisoft|mtxinu}!taniwha!paul (415)420-8179 Taniwha Systems Design, Oakland CA "Read my lips .... no GNU taxes"