Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 2 Dec 1997 00:46:10 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        hasty@netcom.com (Amancio Hasty Jr)
Cc:        hasty@rah.star-gate.com, wosch@cs.tu-berlin.de, hackers@freebsd.org
Subject:   Re: ftp server on ftp.cdrom.com
Message-ID:  <199712020046.RAA25522@usr07.primenet.com>
In-Reply-To: <199712012138.NAA03509@netcom14.netcom.com> from "Amancio Hasty Jr" at Dec 1, 97 01:38:40 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> Actually, I was thinking more along the lines of state machine with
> the functionality to share data transfers you know to avoid the
> case of hundreds of users opening a single file N times.
> 
> Most network engineers are familiar with an event or a state machine
> driven network server .

Converting a sync call into an async call plus a context switch is
the general mechanism whereby you implement usr space threading
(this is *exactly* what liblwp in SunOS 4.1.3 does, not to be
confused with LWP from Solaris 2.x, where Sun reused the name).

Topologically, there's no difference between using threading
that does call conversion, or doing the call conversion yourself
and maintaining a per client state structure instead of relying
on the thread local storage/stack to do it for you.

The difference is one of programming API more than model.

The kernel threading uses a different model, but is broken in
other ways (a blocking call on a user thread blocks the kernel
schedulable entity, you must give up your CPU in order to make
a blocking call, even though your process has more work it's
ready to do, etc.).

Whenever you say "I want to do call conversion", you are really
saying "I want to implement application specific light weight
threading".


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712020046.RAA25522>