On Thu, Feb 22, 2007 at 05:52:10PM -0800, Scott Lamb wrote:
[...]
> What about just never using sigprocmask() or pthread_sigmask()? The
> patch I sent to the list a while back fixes two bugs:
>
> * prevents Anton Povarov's reported race in which a signal delivered
> quickly after event_signal_
On Feb 22, 2007, at 6:32 PM, Niels Provos wrote:
Do you have an addition to the regression test that would allow me to
verify that the new code works as intended? If not, it would be most
appreciated :-)
There is one that verifies the quickly received signal case. Are you
talking about th
Do you have an addition to the regression test that would allow me to
verify that the new code works as intended? If not, it would be most
appreciated :-)
Niels.
On 2/22/07, Scott Lamb <[EMAIL PROTECTED]> wrote:
On Feb 21, 2007, at 1:29 AM, William Ahern wrote:
> On Wed, Feb 21, 2007 at 03:
On Feb 21, 2007, at 1:29 AM, William Ahern wrote:
On Wed, Feb 21, 2007 at 03:44:58AM -0500, Nick Mathewson wrote:
libevent, "I'm going to use pthreads; use pthread_sigmask()
instead of
sigprocmask()." I don't know what that interface should be, but the
corresponding code should be pretty s
William Ahern wrote:
I admittedly don't no anything about IOCP. What I do no is that it doesn't
make sense to use any other function call then send() or sendto() to write
out UDP data. So whatever API your writing around IOCP, it should
short-circuit for UDP writes; just call send() to sendto().
On Thu, Feb 22, 2007 at 09:01:00PM +, Toby Douglass wrote:
> However, I've just realized that it may make no difference.
>
> Writing to a UDP socket should never block; agreed.
>
> However, that multiple concurrent writes (one socket, many writer
> threads) can occur, and so the internal mec
On Thu, Feb 22, 2007 at 08:26:22PM +, Toby Douglass wrote:
> >Likely what the NIC can push out and what the link can
> >handle is different, so trying to cater to the output buffer is a futile
> >excercise, as far as I can see.
>
> So, the final implication is that users will ONLY ever perfor
Toby Douglass wrote:
William Ahern wrote:
On Thu, Feb 22, 2007 at 01:43:48PM -, Toby Douglass wrote:
However, the example I had in mind (which is similar) is P2P apps, which
use writes on a single local UDP socket to send peering information to
peers. They would benefit from async writes
William Ahern wrote:
On Thu, Feb 22, 2007 at 01:43:48PM -, Toby Douglass wrote:
However, the example I had in mind (which is similar) is P2P apps, which
use writes on a single local UDP socket to send peering information to
peers. They would benefit from async writes on that socket.
Wri
On Thu, Feb 22, 2007 at 01:43:48PM -, Toby Douglass wrote:
> > From: "Toby Douglass" <[EMAIL PROTECTED]>
> >> As it is, it's easy to support serial writes with IOCP, it's supporting
> >> multiple concurrent writes which is awkward for a convenient-to-use API
> >> over IOCP - and this I would th
From: "Toby Douglass" <[EMAIL PROTECTED]>
I wrote:
> On a related note, did someone say that the event handle in the overlapped
> structure used by the IO functions (ReadFile, etc) is not actually used?
>
> If that's actually untouched, I could use it for my own purposes. The
> alternative is pr
> From: "Toby Douglass" <[EMAIL PROTECTED]>
>> As it is, it's easy to support serial writes with IOCP, it's supporting
>> multiple concurrent writes which is awkward for a convenient-to-use API
>> over IOCP - and this I would think is absolutely required for some uses
>> of UDP sockets.
> I haven'
12 matches
Mail list logo
