i was a few days offline, so sorry for my
delayed reply.
I am telling this because I just completed the ns_http
rewrite that handles more/less similar issue w.r.t
queued http reads/writes and I was using the same
cut/splice technique to open a channel in one and
read/write to it in the other thr
On Fri, 7 Jun 2019 11:45:59 +0200
Zoran Vasiljevic wrote:
> At some time, if needed, the writer can be expanded
> to understand Tcl channels as well.
OK. Back-off. That would never work that way.
Because the channel needs to be tossed back
and forth, at lest 2 times. Once for the first
write a
We could use this as well for special purpose logs, e.g. payment logs or
for user deletions and pseudonymizations which conform to GDPR standards.
Am 07.06.19 um 11:25 schrieb Gustaf Neumann:
On 06.06.19 23:09, Gustaf Neumann wrote:
Not sure, what your performance constraints are, but open/clo
On Fri, 7 Jun 2019 11:25:19 +0200
Gustaf Neumann wrote:
> Working with the numeric file descriptors has the advantage that it can be
> passed around between interpreters/threads, etc., so it is well suited
> for multi threaded applications, the FDs of open files can be kept
> in nsvs, etc.).
...
On 06.06.19 23:09, Gustaf Neumann wrote:
Not sure, what your performance constraints are, but open/close
is pretty fast these days (measured under linux on openacs.org):
% time {set F [open /tmp/foo a]; puts $F x; close $F} 1000
55.333 microseconds per iteration
if this is too slow for y
On Thu, 6 Jun 2019 15:49:29 -0400
Andrew Piskorski wrote:
> However, (particularly given my small writes to many files), clearly
> asynchronous file IO should be more efficient, and scale better, so
> I'd like to understand how to do that. The ease of simply calling
> "fconfigure" on a file hand
On 06.06.19 21:49, Andrew Piskorski wrote:
The easiest thing to do is call Tcl's open, puts, close every single
time I need to write data, but that's blocking, and I'm worried that
it could easily degrade the latency of my main processing thread.
by "main thread" you refer probably to the "curre
On Thu, Jun 06, 2019 at 09:23:12PM +0200, Gustaf Neumann wrote:
> The main question is, why are you interested in async writes?
My original use case wasn't clear? I have one thread busy processing
data and sending it various places. I want to log some of that data
to a bunch of files, probably
On 06.06.19 18:26, Andrew Piskorski wrote:
From inside NaviServer, I'd like to repeatedly write data to some
files in the background,
I assume you want to consume data from remote?
No, the data isn't being uploaded by clients, it's received or
generated server-side. Think a streaming data f
On Thu, Jun 06, 2019 at 07:22:08PM +0200, Zoran Vasiljevic wrote:
> There are also writer threads that spool files in a dedicated thread thus
> offloading the connection threads.
I see AsyncWriterThread() in "naviserver/nsd/driver.c", but I don't
really understand the code, nor how it could be us
There are also writer threads that spool files in a dedicated thread thus
offloading the connection threads.
Am 6. Juni 2019 18:26:52 MESZ schrieb Andrew Piskorski :
>On Thu, Jun 06, 2019 at 05:23:38PM +0200, Zoran Vasiljevic wrote:
>> > From inside NaviServer, I'd like to repeatedly write data t
On Thu, Jun 06, 2019 at 05:23:38PM +0200, Zoran Vasiljevic wrote:
> > From inside NaviServer, I'd like to repeatedly write data to some
> > files in the background,
> I assume you want to consume data from remote?
No, the data isn't being uploaded by clients, it's received or
generated server-si
On Thu, 6 Jun 2019 10:41:02 -0400
Andrew Piskorski wrote:
> From inside NaviServer, I'd like to repeatedly write data to some
> files in the background,
I assume you want to consume data
from remote? In that case you may
want to use spooler thread(s):
#
>From inside NaviServer, I'd like to repeatedly write data to some
files in the background, while letting the thread that schedules the
writes go on to do other work. The obvious way to do that might seem
be simply calling Tcl's "open" on each file and then doing:
fconfigure $fd -blocking 0
Ho
14 matches
Mail list logo
