[Ns-developers] [ns3] a synchronous socket/posix API

[Gustavo Carneiro]

On 05/04/2008, Mathieu Lacage <mathieu.lacage at sophia.inria.fr> wrote:
>
>
> On Fri, 2008-04-04 at 23:19 -0700, Sam Jansen wrote:
> > I read through the code this evening and have a couple of minor
> > comments. Also replies to your comments below.
> >
> > I think the approach looks fine, and I really believe in having this
> > ability available in ns-3. Good work!
> >
> > When first reading the code, it was not obvious to me at first how the
> > "ProcessDelayModel" interacted with the scheduler and what it's
> > purpose was, especially just after reading the interface in the header
> > file. I imagine just some documentation would sort this out when this
> > is tidied up for the main tree.
>
> yes, documentation is needed there. But to answer your question, the
> expectation is that this class is used to modelize the time of execution
> of each process. I suspect that most people won't care and will be happy
> with the default here which is to measure the execution time of the code
> we are running and use this as the execution time of the code we are
> modelizing. I have known crazy people who wanted to use more fancy
> models based on measurements of instruction counts of real world code.


This is interesting, but I think it should apply also to regular event based
async simulations.  For instance, when simulating OLSR with many nodes, the
time spend doing routing table or MPR set computations becomes far from
negligible.

On the other hand, modelling process CPU time by measurements of CPU time
spent on a simulator running on a Xeon processor may provide timings that
are far from a real world implementation running on a much slower ARM CPU.

So, very good intentions, but the problem is more complex to solve fully.
:-/

>
> > Why is "src/process/fiber-context-sysv.c" a C file rather than a C++
> > file? I don't see any reason for this to be the case in a C++ project;
>
> I wrote that code a long time ago in yans so, I don't remember why I did
> that. It might be actually the case that I wrote that code before yans
> in another C-based project. Can't remember.
>
> >  all other files are C++ files. Also, note it appears to currently be
> > treated as a C++ file anyway [1].
>
> ok.


Yes, that's because of the current WAF architecture, where you tell WAF
which  tool to use to compile what.  In trunk, I think WAF can already
compile a mix of C, C++, D, whatever, and autodetect which tool to use from
the file extension.

>
> > "void FiberContextSwitchTo (struct FiberContext *from, struct
> > FiberContext const *to)"
> >
> > It seems to me that the interface shouldn't enforce const-ness in the
> > "to" pointer here. A pthreads-based implementation would need to
> > modify members of this pointer to e.g., lock a mutex. A common way to
> > get around this in C++ would be to make the mutexes "mutable", but
> > this can't be done if the file is a C file [2].
>
> ok.
>
> >
> > I put together a quick pthread implementation and it's also quite
> > simple, a similar amount of code as the current fiber-context
> > implementation. I'd send a patch, but I can't figure out how to make
>
> ok. I guess that what you could do is leave the fiber-context-sysv.c
> file and rename it to fiber-context-ucontext.c, and, then implement
> fiber-context-pthread.cc (or just leave me the task of doing that
> renaming). The latter will be very cool when running this code in gdb
> because gdb will be smart enough to stop stack unwinding when reaching
> the top of each thread's stack. I have not yet found out how to make it
> do the same trick for the ucontext version. Need to spend time reading
> its code :)
>
> >  waf do a configure check for the existence of *context functions. Is
> > there any documentation for the waf configure interface? The waf
> > website was thoroughly unhelpful here.
>
> Yes, it is pretty unhelpful: gustavo would know how to do that though.


There's an example in waf source code demos/adv/wscript:

    e = conf.create_function_enumerator()
    e.mandatory = 1
    e.headers = ['time.h']
    e.include_paths = ['/usr/include']
    e.function = 'mktime'
    e.define = 'MKTIME'
    e.run()

In this case, we want e.mandatory = 0, and check the return value of e.run()
and do something based on it (it returns a value that evaluates to true if
the function is found, false otherwise). Example:

def configure(conf):
    # ...
    if e.run():
        conf.env['ENABLE_SOMETHING'] = True

def build(bld):
    if bld.env()['ENABLE_SOMETHING']:
        module.source  += " foo.cc"

I can help with the details later, if needed.

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert