On Apr 30, 2007, at 9:28 PM, Garrett D'Amore wrote:
Nicolas Williams wrote:
On Tue, Apr 24, 2007 at 09:23:30PM +0100, Jeremy Harris wrote:
- I'd have been tempted to stick with a synchronous interface for
the
initial development; lose the event notification. Is there
significant
demand from potential customers, which wouldn't be satisfied by
them
creating threads?
It's easier to develop an async API and layer sync on top than to
first
develop a sync API and later re-whack it into an async API.
Of course, it's easier to develop a sync API and stop there, but
really,
we need async interfaces -- everything seems to nowadays (from GUI
programming, starting decades ago, to Ajax now).
That is certainly true of many APIs that were designed to operate
in the absence of threading. However, a kernel API where threads
are readily available probably shouldn't have to deal with the
complexity of an async. API, IMO.
Think of the NFS server with 1000s connections to manage.
Either the ksocket API provides async events or the kernel RPC
layer will need to build something on its own. I prefer the former.
Spencer
_______________________________________________
networking-discuss mailing list
[email protected]
