Am 04.01.2006 um 06:20 schrieb Vlad Seryakov:
I am attaching the whole driver.c file because patch would not be
very readable.
Won't go as the list limits the message to 40K.
Go and upload it into the RFE. That should work.
Zoran
I am attaching the whole driver.c file because patch would not be very
readable.
See if this a good solution or not, it works and uses separate thread
for all reading and spooling, also all upload stats are done in the
spoller thread, so driver thread now works without any locking.
Vlad Sery
Stephen Deasey wrote:
The driver thread gets the connection and reads all up to maxreadahead.
It then passes the connection to the conn thread.
The conn thread decides to run that connection entirely (POST of a
simple form
or GET, all content read-in) OR it decides to pass the connection to the
s
I submitted Service Request with new patch with spooler support. Very
simple but seems to be working well.
Zoran Vasiljevic wrote:
Am 03.01.2006 um 16:47 schrieb Vlad Seryakov:
Spool thread can be a replica of driver thread, it will do the same
as driver and then pass Sock to the conn threa
Am 03.01.2006 um 16:47 schrieb Vlad Seryakov:
Spool thread can be a replica of driver thread, it will do the same
as driver and then pass Sock to the conn thread. So making it C-
based is not that hard and still it will be fast and small.
Plus, upload statistics now will be handled in the sp
Am 03.01.2006 um 18:50 schrieb Stephen Deasey:
What happens to the conn thread after this? It can't wait for
completion, that would defeat the purpose.
Do traces (logging etc.) run now, in the conn thread, or later in a
spool thread? If logging runs now, but the upload fails, the log will
be w
On 1/3/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
>
> Am 03.01.2006 um 01:07 schrieb Vlad Seryakov:
>
> >
> > Will it be more generic way just to set upper limit, if we see that
> > upload exceeds that limit, pass control to conn thread and let it
> > finish reading, this way, even spooling to
Spool thread can be a replica of driver thread, it will do the same as
driver and then pass Sock to the conn thread. So making it C-based is
not that hard and still it will be fast and small.
Plus, upload statistics now will be handled in the spool thread, not
driver thread, so no overhead and
Am 03.01.2006 um 11:21 schrieb Andrew Piskorski:
Hm, does Tcl support asynchronous (non-blocking) IO for both network
sockets and local files? Tcl has 'fconfigure -blocking 0' of course,
but I don't know for sure whether that really does what you want for
this application. If Tcl DOES support
Am 03.01.2006 um 10:49 schrieb Bernd Eidenschink:
Of course, AJAX is still evolving and so are browser features, it's
good to
have stats and it is often requested, but for now there are use
cases where
the client approach is still better.
All very true...
The ultimate solution is: both.
On Tue, Jan 03, 2006 at 09:49:02AM +0100, Zoran Vasiljevic wrote:
> The spooling threads operate in event-loop mode. There has to be
> some kind of dispacher which evenly distributes the processing among
> spooling threads.
Or just start out with one spool thread, support for multiple spool
threa
>o. add upload statistics and control?
Reading the current very interesting thread, I would vote for adding it, if
the stats are some kind of by-product of more stability against DOS attacks,
multiple slow clients, reducing memory needs etc. as you all pointed out.
Because what is still not
Am 03.01.2006 um 01:07 schrieb Vlad Seryakov:
Will it be more generic way just to set upper limit, if we see that
upload exceeds that limit, pass control to conn thread and let it
finish reading, this way, even spooling to file will work, because
each upload conn thread will use their own
13 matches
Mail list logo
