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

[Mathieu Lacage]

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.

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

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

regards,
Mathieu