aboutsummaryrefslogtreecommitdiff
path: root/pipermail/nel/2001-March/000316.html
blob: b6f93e2c1f4a9480f4b3a4cc3040834ae4ecf127 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
 <HEAD>
   <TITLE> [Nel] NeL Network Engine</TITLE>
   <LINK REL="Index" HREF="index.html" >
   <LINK REL="made" HREF="mailto:dayta%40ucc.gu.uwa.edu.au">
   <LINK REL="Previous"  HREF="000314.html">
   <LINK REL="Next" HREF="000313.html">
 </HEAD>
 <BODY BGCOLOR="#ffffff">
   <H1>[Nel] NeL Network Engine</H1>
    <B>Leighton Haynes</B> 
    <A HREF="mailto:dayta%40ucc.gu.uwa.edu.au"
       TITLE="[Nel] NeL Network Engine">dayta@ucc.gu.uwa.edu.au</A><BR>
    <I>Thu, 1 Mar 2001 17:33:07 +0800</I>
    <P><UL>
        <LI> Previous message: <A HREF="000314.html">[Nel] NeL Network Engine</A></li>
        <LI> Next message: <A HREF="000313.html">[Nel] STLPort...</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#316">[ date ]</a>
              <a href="thread.html#316">[ thread ]</a>
              <a href="subject.html#316">[ subject ]</a>
              <a href="author.html#316">[ author ]</a>
         </LI>
       </UL>
    <HR>  
<!--beginarticle-->
<PRE>On Thu, Mar 01, 2001 at 09:52:21AM +0100, Vincent Archer wrote:
&gt;<i> According to Leighton Haynes:
</I>&gt;<i> &gt; I'm not sure if this is a really important issue right now. As many
</I>&gt;<i> &gt; people have noted, premature optimization is the source of all evil. 
</I>&gt;<i> 
</I>&gt;<i> It is somewhat important. There are optimisations that can be done further,
</I>&gt;<i> but there are also fundamental design issues that reflect how everything
</I>&gt;<i> else in the server code has to be written.
</I>&gt;<i> 
</I>&gt;<i> You do not program an event-driven system like you would on a thread-based
</I>&gt;<i> system. Converting from one model to another would be horribly painful,
</I>&gt;<i> which is why the &quot;right&quot; one has to be selected. Once we pick one, we'll
</I>&gt;<i> have to stick by it, and the more code is produced under a model, the
</I>&gt;<i> 
</I>&gt;<i> Which is why the decision about this was deferred until it can no longer
</I>&gt;<i> be truly avoided.
</I>
*ponder*

I can't see the fundamental difference between an event-driven and
a thread-based model. In an event-driven model , some central arbiter
gets the input, grabs the data representing the 'entity', processes it, 
and sends a reply. In a thread-based model, each entitiy is a thread,
the entity receives a message , processes it, and sends a reply. 
The fundamental differences, are in the message addressing, and 
the context switching. 

What are the issues here? So far I've seen only discussion of
how many threads we can handle, which doesn't seem to be the 
central issue. What we really need, is a list of the requirements
for this particular sub-system. (Perhaps they exist somewhere, 
but I haven't seen them).


Leighton...

--

Part-time student. Full-time Programmer. 
Seeking the 36 hour day and the 10 hour working week.
(08) 9272 9058 (Home - like I'm ever there)
0401 335 136 (Mobile - like it's ever on)

</pre>

<!--endarticle-->
    <HR>
    <P><UL>
        <!--threads-->
	<LI> Previous message: <A HREF="000314.html">[Nel] NeL Network Engine</A></li>
	<LI> Next message: <A HREF="000313.html">[Nel] STLPort...</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#316">[ date ]</a>
              <a href="thread.html#316">[ thread ]</a>
              <a href="subject.html#316">[ subject ]</a>
              <a href="author.html#316">[ author ]</a>
         </LI>
       </UL>
</body></html>