naviserver-devel — Developer discussion

Re: [naviserver-devel] maxinput/maxpost: why both?

[Stephen D. <sd...@gm...>]

On 6/16/05, Zoran Vasiljevic <zv...@ar...> wrote:
>=20
> Am 16.06.2005 um 19:40 schrieb Vlad Seryakov:
>=20
> > It looks like maxpost just checks Content-Length: header, it is not
> > hard limit like maxinput which limits the real memory buffer for
> > uploaded content.
> >
>=20
> As I see, the maxpost test can be easily dwarfed by somebody giving the
> content-length of -1 (or less). In that case the code in SockRead()
> at the line 1481 will just ignore the maxpost setting:
>=20
>              s =3D Ns_SetIGet(reqPtr->headers, "content-length");
>              if (s !=3D NULL) {
>                  reqPtr->length =3D atoi(s);
>                  if (reqPtr->length < 0
>                      && reqPtr->length > sockPtr->drvPtr->servPtr-
>  >limits.maxpost) {
>                      return SOCK_ERROR;
>                  }
>              }
>=20
> See? If the content-length is set to some other meaningful value (>=3D
> 0) then the
> test is OK. But if not, then maxinput is really useless.
> I would suggest we simply junk the maxpost knob and rely on the
> maxinput only.
> This will make life easier.


Yeah, this broken test looks redundant.

Re: [naviserver-devel] maxinput/maxpost: why both?

[Zoran V. <zv...@ar...>]

Am 16.06.2005 um 19:40 schrieb Vlad Seryakov:

> It looks like maxpost just checks Content-Length: header, it is not  
> hard limit like maxinput which limits the real memory buffer for  
> uploaded content.
>

As I see, the maxpost test can be easily dwarfed by somebody giving the
content-length of -1 (or less). In that case the code in SockRead()
at the line 1481 will just ignore the maxpost setting:

             s = Ns_SetIGet(reqPtr->headers, "content-length");
             if (s != NULL) {
                 reqPtr->length = atoi(s);
                 if (reqPtr->length < 0
                     && reqPtr->length > sockPtr->drvPtr->servPtr- 
 >limits.maxpost) {
                     return SOCK_ERROR;
                 }
             }

See? If the content-length is set to some other meaningful value (>=  
0) then the
test is OK. But if not, then maxinput is really useless.
I would suggest we simply junk the maxpost knob and rely on the  
maxinput only.
This will make life easier.

Zoran

Re: [naviserver-devel] maxinput/maxpost: why both?

[Vlad S. <vl...@cr...>]

It looks like maxpost just checks Content-Length: header, it is not hard 
limit like maxinput which limits the real memory buffer for uploaded 
content.

Zoran Vasiljevic wrote:
> Hi!
> 
> Related to the file upload issue, I was walking arrund the code
> and do not understand why there are two limits for incoming
> content?
> 
> I see that maxinput is defined per-socket-driver (thanks Vlad)
> and maxpost is defined per-virtual-server.
> 
> Are there any reasons to maintain these two in future?
> The newest code (4.5) in AS project seems to have dropped
> the maxpost entirely.
> 
> Zoran
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

[naviserver-devel] maxinput/maxpost: why both?

[Zoran V. <zv...@ar...>]

Hi!

Related to the file upload issue, I was walking arrund the code
and do not understand why there are two limits for incoming
content?

I see that maxinput is defined per-socket-driver (thanks Vlad)
and maxpost is defined per-virtual-server.

Are there any reasons to maintain these two in future?
The newest code (4.5) in AS project seems to have dropped
the maxpost entirely.

Zoran

Re: [naviserver-devel] uploading large files

[Zoran V. <zv...@ar...>]

Am 16.06.2005 um 18:18 schrieb Zoran Vasiljevic:

>
> One can even explore the memmap machinery and see if we can
> entirely drop the temp-file and use the system paging for that:
> so if the input exceeds the maxinput, we just mmap /dev/zero file
> I believe something like that should be possible but will have to
> double-check if this is true.
>

I knew it ("man mmap" on solaris):


      When MAP_ANON is set in flags, and fd is set to  -1,  mmap()
      provides  a  direct  path  to  return anonymous pages to the
      caller.  This operation is equivalent to passing  mmap()  an
      open  file descriptor on /dev/zero with MAP_ANON elided from
      the flags argument.

I'd have to see if this is really working on Linux, Mac and Win.
Zoran

[naviserver-devel] uploading large files

[Zoran V. <zv...@ar...>]

Hi!

I ran into several problems while debuggging a problem at the
customer site related to uploading files and size of those files.

As it looks like, the NS/AS spools all the incoming content into
the memory (urks!). Depending on the content-type, the content
may be parsed, as in case of multipar/form-data.

This is very convenient (you need not fiddle with the low-level
stuff) but it can be extremely inefficient and bloat the memory
footprint of the server if somebody likes to upload 10's or 100's
of MB of data.

I have examined the recent changes in the AS done by Jim which
tackle this issue. He's basically using the "maxinput" config
option to decide wether to stuff everything into memory (as usual)
or, in the case input exceeds the maxinput level,  stuff the
input into a temporary file. But... the programmer is then left
alone and has to parse the incoming input by himself by using
ns_conn contentchannel command to read the content.
Even more, the form machinery which is basically parsing the
multipart data still operates on the connPtr->content which
does not reflect the entire content (the excessive is spooled
into a temp file!).

Hm... this seems pretty unusable for this particular case to me.

Therefore, and as usual, I have a idea/suggestion how to improve
this...

I would take the same direction as Jim did, but will simply mmap the
temp-file to the connPtr->content! This will make all the rest
of the code work as usual. On the connection end, the file will
be unmmaped and there you go.

One can even explore the memmap machinery and see if we can
entirely drop the temp-file and use the system paging for that:
so if the input exceeds the maxinput, we just mmap /dev/zero file
I believe something like that should be possible but will have to
double-check if this is true.

Now, what do you  think?

Zoran

Re: [naviserver-devel] URGENT: is there any limitation on upload file size?

[Zoran V. <zv...@ar...>]

Am 16.06.2005 um 11:06 schrieb Bernd Eidenschink:

> ns_section "ns/server/${servername}"
> ns_param   maxpost      1024*1024*10  ;# 10 MB  (default: 256k?)
>

Thanks a lot!
Zoran

Re: [naviserver-devel] URGENT: is there any limitation on upload file size?

[Bernd E. <eid...@we...>]

> Before I start to dig, does anybody know wether there is
> a limitation somewhere in the config about size of the
> uplading files in NS? In the AS 4.0 there wasn't IIRC.

ns_section "ns/server/${servername}"
ns_param   maxpost      1024*1024*10  ;# 10 MB  (default: 256k?)

there is a related param "maxinput"; they have subtle (minor) differences
as i heard from prior discussions (regarding content<->headers), but it should 
be safe to set maxpost and maxinput to the same (high) values.

Regards,
Bernd.

[naviserver-devel] URGENT: is there any limitation on upload file size?

[Zoran V. <zv...@ar...>]

Hi !

Before I start to dig, does anybody know wether there is
a limitation somewhere in the config about size of the
uplading files in NS? In the AS 4.0 there wasn't IIRC.

Cheers
Zoran

Re: [naviserver-devel] Re: RFE #1202462

[Zoran V. <zv...@ar...>]

Am 15.06.2005 um 09:26 schrieb Stephen Deasey:

> On 6/15/05, Zoran Vasiljevic <zv...@ar...> wrote:
>
>>
>> Am 15.06.2005 um 08:54 schrieb Stephen Deasey:
>>
>>>
>>> How will you load modules at startup?  dlopen() etc. take a file =20
>>> name.
>>>
>>>
>>
>> I will start with this and see if it suffices:
>>
>>         Tcl_FSLoadFile  dynamically  loads  a  binary code file into
>> memory and
>>         returns the addresses of two procedures within that file, if
>> they  are
>>         defined.   The appropriate function for the filesystem to
>> which pathPtr
>>         belongs will be called.  If that filesystem  does  not
>> implement  this
>>         function  (most virtual filesystems will not, because of OS
>> limitations
>>         in dynamically loading binary code), Tcl will attempt to copy
>> the  file
>>         to a temporary directory and load that temporary file.
>>
>
>
> Oh, that'll work.
>
> How about registering your own handler on /* just as the core server
> does at startup?  That way the fastpath code won't be called unless
> you explicitly call it.  You can send files using
> Ns_ConnSendChannel().

I believe we are basically talking about this code in fastpath.c:

         if (servPtr->fastpath.mmap
             && NsMemMap(file, stPtr->st_size, NS_MMAP_READ, &fmap) =20
=3D=3D NS_OK) {
             result =3D Ns_ConnReturnData(conn,status, =20
fmap.addr,fmap.size, type);
             NsMemUmap(&fmap);
         } else {
             fd =3D open(file, O_RDONLY | O_BINARY);
             if (fd =3D=3D -1) {
                 Ns_Log(Warning, "fastpath: open(%s) failed: %s", file,
                        strerror(errno));
                 goto notfound;
             }
             result =3D Ns_ConnReturnOpenFd(conn, status,type, fd,stPtr-=20=

 >st_size);
             close(fd);
         }

I recently added wrappers for platform-neutral mmap. I can imagine
something like:

         if (servPtr->fastpath.mmap
             && NsMemMap(file, stPtr->st_size, NS_MMAP_READ, &fmap) =20
=3D=3D NS_OK) {
             result =3D Ns_ConnReturnData(conn,status, =20
fmap.addr,fmap.size, type);
             NsMemUmap(&fmap);
         =10=10=10=10=10=10=10=10=10=10=10=10=10=10=10=10} else if =
(servPtr->fastpath.vfs
             && NsVfsLoad(file, buf) =3D=3D NS_OK) {
             result =3D Ns_ConnReturnData(conn, status, buf, stPtr-=20
 >st_size, type);
         } else {
             fd =3D open(file, O_RDONLY | O_BINARY);
             if (fd =3D=3D -1) {
                 Ns_Log(Warning, "fastpath: open(%s) failed: %s", file,
                        strerror(errno));
                 goto notfound;
             }
             result =3D Ns_ConnReturnOpenFd(conn, status,type, fd,stPtr-=20=

 >st_size);
             close(fd);
         }

This will induce absolutely no performance hit and it is about only
place where speed matters, AFAIK.

Zoran

Re: [naviserver-devel] Re: RFE #1202462

[Zoran V. <zv...@ar...>]

Am 15.06.2005 um 09:26 schrieb Stephen Deasey:

>
> How about registering your own handler on /* just as the core server
> does at startup?  That way the fastpath code won't be called unless
> you explicitly call it.  You can send files using
> Ns_ConnSendChannel().
>

I believe there are some side-effect on overloading the entire root
with a custom handler... I cannot recall exactly, but I know there are.

Zoran

Re: [naviserver-devel] codestyle

[Zoran V. <zv...@ar...>]

Am 15.06.2005 um 09:23 schrieb Stephen Deasey:

>> Why would you remove the Makefile/header? OK, those are not code- 
>> style
>> directives but are helpful for module writers.
>>
>
>
> I think nsexample should become the template.  New module writers
> would simply copy the whole thing into a new directory and start
> editing.
>

OK. This makes sense.
Zoran

Re: [naviserver-devel] binder, sockets

[Zoran V. <zv...@ar...>]

Am 15.06.2005 um 09:20 schrieb Stephen Deasey:
>>
>> In the process of cleanup, we might rectify/improve this and
>> give the calls more meaningful names.
>>
>
>
> Hmm, I don't think this naming scheme is clarifying things.  The
> situation is that Ns_SockListenRaw() does not in fact listen.  It call
> down to Ns_SockBindRaw() which does not in fact bind...

As I already said above... it is not very meaningful but it follows
the

    first bind, then listen

for *all* types of sockets. So no matter what socket you use, you
might want to bind to the socket (yes, privlieged operation)
then listen. The current listen calls are already clever to
honour the pre-binded sockets and use them, binding only
when needed. So, technically speaking you do not need the
explicit bind, or?

>
> I think we have to assume that programmers who need to use UDP and raw
> sockets have some idea of how they work.  Pretending that they listen
> and/or bind is probably just going to confuse them.

If you look at it from that angle, then yes.

>
> Isn't bind() the privileged call here, not listen?  I think the hash
> look-up needs to be pushed down into the bind calls.  Then ListenUdp
> and BindRaw can be dropped.  And ListenUnix still needs a backlog
> arg...
>

I will check this (havent thought much about the real functionality
while unifiying call-names, as said before).

> Oh, and Ns_SockListenUnix(char *path) is yet another thing that won't
> work with the Tcl VFS...   :-)

I have no problem with that. The fact is that most people also need temp
directories and those must be somewhere on the filesystems, like pipes,
unix-domain sockets and stuff like that. The VFS should really aid in
getting the software distribution simpler to a greater extent. The
ultimative is to pack everything (I mean *everything*) into a monolit
file and distribute this file only (starkit). But, during the *runtime*
things are going to be done in the native filesystem (the example avove,
the temporary directory, loading shared librarries, etc etc).
So, I'm heaading slowly towards "being able to pack everything". One of
the steps I see on the road ahead is "package req NaviServer" which  
would
make us just-another-tcl-extension which everybody could use.

Zoran

Re: [naviserver-devel] Re: RFE #1202462

[Stephen D. <sd...@gm...>]

On 6/15/05, Zoran Vasiljevic <zv...@ar...> wrote:
>=20
> Am 15.06.2005 um 08:54 schrieb Stephen Deasey:
> >
> > How will you load modules at startup?  dlopen() etc. take a file name.
> >
>=20
> I will start with this and see if it suffices:
>=20
>         Tcl_FSLoadFile  dynamically  loads  a  binary code file into
> memory and
>         returns the addresses of two procedures within that file, if
> they  are
>         defined.   The appropriate function for the filesystem to
> which pathPtr
>         belongs will be called.  If that filesystem  does  not
> implement  this
>         function  (most virtual filesystems will not, because of OS
> limitations
>         in dynamically loading binary code), Tcl will attempt to copy
> the  file
>         to a temporary directory and load that temporary file.


Oh, that'll work.

How about registering your own handler on /* just as the core server
does at startup?  That way the fastpath code won't be called unless
you explicitly call it.  You can send files using
Ns_ConnSendChannel().

Re: [naviserver-devel] codestyle

[Stephen D. <sd...@gm...>]

On 6/15/05, Zoran Vasiljevic <zv...@ar...> wrote:
>=20
> Am 15.06.2005 um 09:06 schrieb Stephen Deasey:
>=20
> > I think we should make nsexample more of a template for reuse, and
> > make the Code Standards document more How and Why.  We'd remove the
> > template Makefile and header etc.
> >
>=20
> Why would you remove the Makefile/header? OK, those are not code-style
> directives but are helpful for module writers.


I think nsexample should become the template.  New module writers
would simply copy the whole thing into a new directory and start
editing.

Re: [naviserver-devel] binder, sockets

[Stephen D. <sd...@gm...>]

On 6/13/05, Zoran Vasiljevic <zv...@ar...> wrote:
>=20
> Am 13.06.2005 um 09:37 schrieb Stephen Deasey:
>=20
> >
> > Ns_SockListenTcp() should probably replace Ns_SockListenEx() with it's
> > backlog parameter?  The passed backlog should be checked, and if it's
> > < 1, use the default from the config file.
> >
> > If this is the new recommended way to listen on sockets, I'd update
> > all callers of the old Ns_SockListen(Ex) functions.  People will cut
> > 'n paste old code and continue the confusion.
>=20
> Well, I have left the Ns_SockListenEx() untouched. We might rename
> it to Ns_SockListenTcp() to be more consistent but I did not want
> to do that yet because I do not know what side-effects this may
> have.
>=20
> >
> > Hmm, Ns_SockListenUnix() doesn't actually call listen().  Is this
> > right?  Also, is a backlog parameter appropraite here, as in
> > Ns_SockListenEx()?
>=20
> No, it does not. It just binds.
> As well as the raw sockets; Ns_SockBindRow does not bind.
> It just creates the socket.
>=20
> I did not want to add complete confusion so I followed the
> TCP way:
>=20
>     ListenXXX
>     BindXXX
>=20
> where XXX =3D Unix, Raw
>=20
> and
>=20
>     Listen
>     Bind
>=20
> is reserved for TCP. The only real exception is Ns_SocketListenEx
> which just adds one additional (backlog) parameter.
>=20
> Admitently, some calls are real misnomers as I already documented
> in the funciton comment:
>=20
> *
> * Ns_SockBindRaw --
> *
> *      Create a raw socket. It does not bind, hence the call name
> *      is not entirely correct but is on-pair with other types of
> *      sockets (udp, tcp, unix).
> *
>=20
> In the process of cleanup, we might rectify/improve this and
> give the calls more meaningful names.


Hmm, I don't think this naming scheme is clarifying things.  The
situation is that Ns_SockListenRaw() does not in fact listen.  It call
down to Ns_SockBindRaw() which does not in fact bind...

I think we have to assume that programmers who need to use UDP and raw
sockets have some idea of how they work.  Pretending that they listen
and/or bind is probably just going to confuse them.

Isn't bind() the privileged call here, not listen?  I think the hash
look-up needs to be pushed down into the bind calls.  Then ListenUdp
and BindRaw can be dropped.  And ListenUnix still needs a backlog
arg...


Oh, and Ns_SockListenUnix(char *path) is yet another thing that won't
work with the Tcl VFS...   :-)

Re: [naviserver-devel] codestyle

[Zoran V. <zv...@ar...>]

Am 15.06.2005 um 09:06 schrieb Stephen Deasey:

> I think we should make nsexample more of a template for reuse, and
> make the Code Standards document more How and Why.  We'd remove the
> template Makefile and header etc.
>

Why would you remove the Makefile/header? OK, those are not code-style
directives but are helpful for module writers.

Zoran

Re: [naviserver-devel] Re: RFE #1202462

[Zoran V. <zv...@ar...>]

Am 15.06.2005 um 08:54 schrieb Stephen Deasey:
>
> How will you load modules at startup?  dlopen() etc. take a file name.
>

I will start with this and see if it suffices:

        Tcl_FSLoadFile  dynamically  loads  a  binary code file into  
memory and
        returns the addresses of two procedures within that file, if   
they  are
        defined.   The appropriate function for the filesystem to  
which pathPtr
        belongs will be called.  If that filesystem  does  not   
implement  this
        function  (most virtual filesystems will not, because of OS  
limitations
        in dynamically loading binary code), Tcl will attempt to copy  
the  file
        to a temporary directory and load that temporary file.

Zoran

Re: [naviserver-devel] codestyle

[Stephen D. <sd...@gm...>]

On 6/14/05, Zoran Vasiljevic <zv...@ar...> wrote:
>=20
> Am 14.06.2005 um 09:31 schrieb Stephen Deasey:
>=20
> >
> > I think this page needs some love:
> >
> > http://naviserver.sourceforge.net/wiki/index.php/Code_Standards
> >
> >
>=20
> I will take the freedom to update each and every page I visit
> to conform to the code-style as above.
> I find the style pretty clean and simple and there should be
> no problems in following it. I will also add to the style-doc
> as I walk thru sources, if I find something missing or too ambiguous.


Well, I don't know that the doc is perfect...

I've imported the nsexample module into CVS:
    http://cvs.sourceforge.net/viewcvs.py/naviserver/modules/nsexample/

I think we should make nsexample more of a template for reuse, and
make the Code Standards document more How and Why.  We'd remove the
template Makefile and header etc.

Re: [naviserver-devel] Re: RFE #1202462

[Stephen D. <sd...@gm...>]

On 6/14/05, Zoran Vasiljevic <zv...@ar...> wrote:
>=20
> Am 01.06.2005 um 20:19 schrieb Zoran Vasiljevic:
>=20
> >> I don't see anything wrong with using Tcl_VFS* directly to read the
> >> config file, write to a log file etc., and the tcl commands in
> >> nsd/tclfile.c should be replaced by simple Tcl wrappers anyway.  It's
> >> the stuff in nsd/fastpath.c that's important.  File descriptors need
> >> to be available for use with modern, high performance system calls
> >> with a minimum of conditional compilation/execution.
> >>
> >> This also has the potential to be a never-ending bug hunt.
> >> Absolutely
> >> every call to the file system has to be converted to Tcl_VFS* or
> >> Ns_VFS*, including all modules and the libraries they wrap, or people
> >> will be surprised...
> >
> >> I'm not against this feature, but it's pretty esoteric and the
> >> implementation is invasive so the quality bar needs to be set high.
> >> I'm sure you can do it  :-)
> >
>=20
>=20
> I have thought about all this...
>=20
> We do have consensus on fact that fastpath code is actually the
> core of the performance respective the filesystem access. All
> other parts where files are read and/or written is not speed
> relevant. Correct?
>=20
> Now, if I simplify the above task by making the *rest* of the
> server VFS aware (replacing all native FS calls with Tcl wrappers)
> and add one additional config-option to fastpath code like the
> mmap is today?
> So, one who needs to serve pages out of container files, would
> simply toggle the:
>=20
>     ns/server/$server/fastpath/vfs
>=20
> switch to 1 (the default would be zero: not use vfs).
> This way, the task is pretty simple and straight-forward.
>=20
> What do you think?


How will you load modules at startup?  dlopen() etc. take a file name.

Re: [naviserver-devel] Re: RFE #1202462

[Zoran V. <zv...@ar...>]

Am 14.06.2005 um 15:39 schrieb Vlad Seryakov:

> My question is: will it affect service Tcl pages as well. For  
> example using templating system it opens .tcl and .adp files. Will  
> Vfs slow down the oevrall performance?


I expected this question!

I believe the overhead of processing an adp page (or Tcl procedure)
will *by far* exceede the actual open/read/close vs. the VFS equivalent.
I think we are there in sub-msec range whereas the actual adp/tcl
execution falls into the msec to 10's or 100's of msec.
I do not believe that this is going to be of any issue.
We can test this by adding a wrapper in the adpcode where the
file is read-in and checking the performance.

Note: the entire Tcl core is using those wrappers. That is, whatever
you do with files from Tcl, everything passes thru VFS layer.

Zoran

Re: [naviserver-devel] Re: RFE #1202462

[Vlad S. <vl...@cr...>]

My question is: will it affect service Tcl pages as well. For example 
using templating system it opens .tcl and .adp files. Will Vfs slow down 
the oevrall performance?

Zoran Vasiljevic wrote:
> 
> Am 01.06.2005 um 20:19 schrieb Zoran Vasiljevic:
> 
>>> I don't see anything wrong with using Tcl_VFS* directly to read the
>>> config file, write to a log file etc., and the tcl commands in
>>> nsd/tclfile.c should be replaced by simple Tcl wrappers anyway.  It's
>>> the stuff in nsd/fastpath.c that's important.  File descriptors need
>>> to be available for use with modern, high performance system calls
>>> with a minimum of conditional compilation/execution.
>>>
>>> This also has the potential to be a never-ending bug hunt.   Absolutely
>>> every call to the file system has to be converted to Tcl_VFS* or
>>> Ns_VFS*, including all modules and the libraries they wrap, or people
>>> will be surprised...
>>
>>
>>> I'm not against this feature, but it's pretty esoteric and the
>>> implementation is invasive so the quality bar needs to be set high.
>>> I'm sure you can do it  :-)
>>
>>
> 
> 
> I have thought about all this...
> 
> We do have consensus on fact that fastpath code is actually the
> core of the performance respective the filesystem access. All
> other parts where files are read and/or written is not speed
> relevant. Correct?
> 
> Now, if I simplify the above task by making the *rest* of the
> server VFS aware (replacing all native FS calls with Tcl wrappers)
> and add one additional config-option to fastpath code like the
> mmap is today?
> So, one who needs to serve pages out of container files, would
> simply toggle the:
> 
>    ns/server/$server/fastpath/vfs
> 
> switch to 1 (the default would be zero: not use vfs).
> This way, the task is pretty simple and straight-forward.
> 
> What do you think?
> 
> Zoran
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you 
> shotput
> a projector? How fast can you ride your desk chair down the office luge 
> track?
> If you want to score the big prize, get to know the little guy.  Play to 
> win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] binder, sockets

[Vlad S. <vl...@cr...>]

Yes, i missed that which means i never tried unix domain sockets yet

Zoran Vasiljevic wrote:
> 
> Am 14.06.2005 um 09:45 schrieb Stephen Deasey:
> 
>> I don't understand why listen() is not called.  You have to do this in
>> order to receive connections, right?
> 
> 
> 
> Eh... Vlad should answer that :-)
> 
> All I did was cosmetically cleaning up the code w/o actually
> going into the functionality. I did not want to change anything
> functionality-wise until he looks over it.
> 
> Zoran
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you 
> shotput
> a projector? How fast can you ride your desk chair down the office luge 
> track?
> If you want to score the big prize, get to know the little guy.  Play to 
> win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] Re: RFE #1202462

[Zoran V. <zv...@ar...>]

Am 01.06.2005 um 20:19 schrieb Zoran Vasiljevic:

>> I don't see anything wrong with using Tcl_VFS* directly to read the
>> config file, write to a log file etc., and the tcl commands in
>> nsd/tclfile.c should be replaced by simple Tcl wrappers anyway.  It's
>> the stuff in nsd/fastpath.c that's important.  File descriptors need
>> to be available for use with modern, high performance system calls
>> with a minimum of conditional compilation/execution.
>>
>> This also has the potential to be a never-ending bug hunt.   
>> Absolutely
>> every call to the file system has to be converted to Tcl_VFS* or
>> Ns_VFS*, including all modules and the libraries they wrap, or people
>> will be surprised...
>
>> I'm not against this feature, but it's pretty esoteric and the
>> implementation is invasive so the quality bar needs to be set high.
>> I'm sure you can do it  :-)
>


I have thought about all this...

We do have consensus on fact that fastpath code is actually the
core of the performance respective the filesystem access. All
other parts where files are read and/or written is not speed
relevant. Correct?

Now, if I simplify the above task by making the *rest* of the
server VFS aware (replacing all native FS calls with Tcl wrappers)
and add one additional config-option to fastpath code like the
mmap is today?
So, one who needs to serve pages out of container files, would
simply toggle the:

    ns/server/$server/fastpath/vfs

switch to 1 (the default would be zero: not use vfs).
This way, the task is pretty simple and straight-forward.

What do you think?

Zoran

Re: [naviserver-devel] website

[Bernd E. <eid...@we...>]

Hi Stephen,

> The thing is, our website isn't the best vehicle for showing off what
> the software can do because the requirements of our website are
> minimal.  One of the most important things is that we're able to just
> forget about it and get on with developing the software.

year, thats true. Let's focus, content like tutorials, help and examples is by 
far more important for the project than an underlying webserver.

btw, the code standards page really looks great!

Regards,
Bernd.