On 10/7/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
Stephen, this is what I got on Tcl core:
Begin forwarded message:
> From: miguel sofer <[EMAIL PROTECTED]>
> Date: 7. Oktober 2006 16:30:05 MESZ
> To: Zoran Vasiljevic <[EMAIL PROTECTED]>
> Cc: miguel <[EMAIL PROTECTED]>, Tcl List Core [E
On 07.10.2006, at 19:00, Stephen Deasey wrote:
But the case where you need to serially execute jobs in the slave can
be handled by either passing them all at once, or by using a
'withhandle' command.
What do you think of the withhandle command? Can you get away with
passing everything to the
We can. It's not that big of a change.
I was just generally holding off on adding new things to the driver
because there's a lot of code in there now and it's getting hard to
manage.
On 10/7/06, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
Stephen,
i checked your patch for AS 4.1 regarding accept
On 10/7/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
On 07.10.2006, at 17:42, Vlad Seryakov wrote:
> to use which, i do not think they are mutual exclusive
This is the impression what I have after all those
emails Although it sounds pretty "opportune" in
the bad sense of the word, I thi
On 07.10.2006, at 17:42, Vlad Seryakov wrote:
to use which, i do not think they are mutual exclusive
This is the impression what I have after all those
emails Although it sounds pretty "opportune" in
the bad sense of the word, I think that a simple
no-nonsense handle-free API + a handle b
What remains:
naming of the module
API (handle vs. handle-free)
ns_exec or ns_slave
i would keep both API, so i would decide in each particular case when
to use which, i do not think they are mutual exclusive
On 07.10.2006, at 17:23, Stephen Deasey wrote:
The caller doesn't have a time budget for executing the code in the
slave, they have a budget for sending the code, executing it, and
receiving the result. So yes, if it takes 5.01 secs with one byte
remaining, you fail. No crystal ball.
OK.
Stephen,
i checked your patch for AS 4.1 regarding acceptmax, we can adopt it
for our driver as well
No, nothing bad. I think it's a great idea!
But some of the newer APIs for this are weird because they handle more
than socket IO, and we are worried about portability, right? I'm just
sayin
On 10/7/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
On 07.10.2006, at 00:51, Stephen Deasey wrote:
> Something else we can try is a Linux and BSD socket option which
> causes a listening socket to only generate a readable event when a new
> socket arrives *and* there is data to read. Usuall
On 10/7/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
On 07.10.2006, at 00:39, Stephen Deasey wrote:
>
> But the call may take longer than the caller budgeted for, due to all
> the hidden timeouts, which are additive.
>
True.
> So the callers time budget is 5 seconds, and that's what they p
On 07.10.2006, at 16:34, Zoran Vasiljevic wrote:
Stephen, this is what I got on Tcl core:
Perhaps it better to refrain from such tricks.
You could maintain a per-interp cache table
in interp-associated-data or something like that.
This way you have exact control and would not be
dependent on
Stephen, this is what I got on Tcl core:
Begin forwarded message:
From: miguel sofer <[EMAIL PROTECTED]>
Date: 7. Oktober 2006 16:30:05 MESZ
To: Zoran Vasiljevic <[EMAIL PROTECTED]>
Cc: miguel <[EMAIL PROTECTED]>, Tcl List Core [EMAIL PROTECTED]>
Subject: Re: [TCLCORE] Lifetime of a literal ob
On 07.10.2006, at 00:51, Stephen Deasey wrote:
Something else we can try is a Linux and BSD socket option which
causes a listening socket to only generate a readable event when a new
socket arrives *and* there is data to read. Usually, you get one when
a new connection arrives, you accept(), th
On 07.10.2006, at 16:16, Stephen Deasey wrote:
You get to fix all the BSD stuff in OSX that Apple back-ported and
fucked up. Enjoy! :-)
I'm already doing (some of) it :-/
On 10/7/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
On 07.10.2006, at 14:42, Stephen Deasey wrote:
>
> This seems kind of arbitrary. What's so special about Linux?
You'll be using Linux like every one else and it won't
matter... :-)
You get to fix all the BSD stuff in OSX that
On 07.10.2006, at 14:42, Stephen Deasey wrote:
This seems kind of arbitrary. What's so special about Linux?
You'll be using Linux like every one else and it won't
matter... :-)
On 07.10.2006, at 00:39, Stephen Deasey wrote:
But the call may take longer than the caller budgeted for, due to all
the hidden timeouts, which are additive.
True.
So the callers time budget is 5 seconds, and that's what they pass to
-evaltimeout. But by default both the sendtimeout and r
On 3/18/06, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
Update of /cvsroot/naviserver/naviserver
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6222
Modified Files:
ChangeLog configure.in
Log Message:
For Linux systems use native crypt which supports MD5 digests, increase
encryption
On 07.10.2006, at 05:59, Vlad Seryakov wrote:
You have a chance to make it nice and come up with some way to combine
them and make cross-referenced. Everything is in our power.
Exactly because of that (nsv) command, I was going to
ask AKU (Andreas KUpries) from ActiveState who wrote
doctools
19 matches
Mail list logo
