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

[Sam Jansen]

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.

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; all other
files are C++ files. Also, note it appears to currently be treated as a C++
file anyway [1].

"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].

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 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.


[1]: When built with "waf -v", I see: "/usr/bin/g++ -Wall -g3 -O0 -DDEBUG
-Werror -fPIC -DPIC  -I. -Idebug -I.. -DRUN_SELF_TESTS -DNS3_ASSERT_ENABLE
-DNS3_LOG_ENABLE -DNS3_MODULE_COMPILATION
../src/process/fiber-context-sysv.c -c -o
debug/src/process/fiber-context-sysv.os" -- waf appears to build the file
with a .c extension with g++, which treats the file as a C++ file.

[2]: Well, it happens to work right now due to [1] above!


<mathieu.lacage at sophia.inria.fr> wrote:
> >
> >  On Fri, 2008-04-04 at 15:50 -0700, Sam Jansen wrote:
> >  > Looks like it is based on makecontext et. al., which are now
> >  > deprecated POSIX functions (see
> >  >
> http://www.opengroup.org/onlinepubs/000095399/functions/makecontext.html
> >  > ). These functions allow one to save and switch stack space, which
> >  > allows you to implement co-operative multitasking in user space.
> >
> >  If they are deprecated, do they have a proposed replacement ?
> >


The link above just says,

"The obsolescent functions getcontext(), makecontext(), and swapcontext()
can be replaced using POSIX threads functions."

I expect the implementations aren't going to go away any time soon though.


> >  >
> >  > It might be useful to have a threads based implementation and fall
> >  > back to that when these aren't available. I've done this with threads
> >  > in the past which isn't too hard, but I found efficiency to be
> lacking
> >  > a bit. Do you test performance at all Mathieu?
> >
> >  No, I have never tested the performance of this approach, although,
> yes,
> >  performance is the classic argument in favor of coroutines since they
> do
> >  not require an extra syscall for each context switch. I expect that, in
> >  our case, where the user code does not do much cpu-intensive tasks,
> >  switching time will dominate so, coroutines will most likely be a
> >  serious performance gain.
> >


My thoughts exactly.

>  However, I have to confess that performance is not the main reason I
> >  picked this approach: I found it easier to implement it that way
> because
> >  I did not have to worry about locking.
> >



Fair enough, understood.