Am 31.12.2005 um 20:12 schrieb Vlad Seryakov:
aio_read/aio_write system calls look like supported ubnder Linux
yes. most of modern os's support some kind of kaio.
I have checked solaris, linux and darwin and all do.
the problem with spawning yet another thread is
system resources. each new t
aio_read/aio_write system calls look like supported ubnder Linux
Zoran Vasiljevic wrote:
Am 31.12.2005 um 19:26 schrieb Vlad Seryakov:
What about separate thread doing all spooling I/O, driver thread will
send buffer to be written and immediately continue while spooling
thread will do writ
Am 31.12.2005 um 19:26 schrieb Vlad Seryakov:
What about separate thread doing all spooling I/O, driver thread
will send buffer to be written and immediately continue while
spooling thread will do writes?
This is another option. I like the kaio because it saves you
yet-another-thread to man
Also, the blocking of the driver thread during spooling
into the file should be taken care. I wanted to look into
the kernel async IO (as it is available on Darwin/Sol/Linux).
What about separate thread doing all spooling I/O, driver thread will
send buffer to be written and immediately conti
Am 31.12.2005 um 19:03 schrieb Vlad Seryakov:
Could config option, like 1 second or 10Kbytes
Yup. For example. This could reduce locking attempts.
Seems fine to me.
Also, the blocking of the driver thread during spooling
into the file should be taken care. I wanted to look into
the kernel asy
Could config option, like 1 second or 10Kbytes
Zoran Vasiljevic wrote:
Am 31.12.2005 um 18:20 schrieb Vlad Seryakov:
Another possible solution can be, pre-allocating maxconn upload
structs and update them without locks, it is integer anyway, so no
need to lock, 4 byte write is never innter
Am 31.12.2005 um 18:20 schrieb Vlad Seryakov:
Another possible solution can be, pre-allocating maxconn upload
structs and update them without locks, it is integer anyway, so no
need to lock, 4 byte write is never innterupted, usually it is 1
CPU instruction(true for Intel, maybe not for Spa
Agreed on that as well, let's do it
Stephen Deasey wrote:
On 12/31/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
Am 31.12.2005 um 01:15 schrieb Gustaf Neumann:
Class Filter
Filter instproc preauth args { }
Filter instproc postauth args { }
Damn, you are right. In which case w
What I have/had in mind is aync writes from the driver thread.
Most of the OS'es have this feature (kaio) so we can employ it.
The question of locking, however still remains in such case.
So the decision has to be made on: what is cheaper? Locking
or spooling to disk out of the conn thread? I hav
I think we talked about this before, but I can't find it in the
mailing list archive. Anyway, the problem with recording the upload
process is all the locking that's required. You could minimize this,
e.g. by only recording uploads above a certain size, or to a certain
URL.
Yes, that is true,
Hi you Navicoders,
my best wishes to you all for (today,tomorrow :-) and 2006!
Bernd.
Am 31.12.2005 um 15:27 schrieb Gustaf Neumann:
Maybe, the receiving thread is not needed at all,
since the driver thread could handle everything as well.
This is what I ment. Driver thread is very hot as it
does not (should not?) find iself into any blocking at all.
At the moment it does, as
Zoran Vasiljevic wrote:
But that would occupy the conn thread for ages, right?
I can imagine several slow-line large-file uploads could
consume many of those. Wasn't that the reason everything
was moved in the driver thread for the 4.0 ?
What I have/had in mind is aync writes from the driver th
Am 31.12.2005 um 11:58 schrieb Stephen Deasey:
I think we talked about this before, but I can't find it in the
mailing list archive. Anyway, the problem with recording the upload
process is all the locking that's required. You could minimize this,
e.g. by only recording uploads above a certai
Am 31.12.2005 um 12:54 schrieb Stephen Deasey:
The order:
TheFilter preauth arg1 arg2
makes the most sense to me. The is not an optional arg, it's
always appended. Required args always come before optional args in
proc specs...
Allright.
If we changed this, we should also change Ns
On 12/31/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
>
> Am 31.12.2005 um 01:15 schrieb Gustaf Neumann:
>
> >
> > Class Filter
> > Filter instproc preauth args { }
> > Filter instproc postauth args { }
> >
>
> Damn, you are right. In which case we'd do:
>
> ns_register_filter
On 12/30/05, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
> On that note i have another idea i'd like to discuss before i even start
> coding a prototype. There is thread on aolserver mailing list about
> upload prgoress, so i thought would it be a good idea to have global
> url-specific cache of all u
17 matches
Mail list logo
