The Proton IOCP implementation provides a reactor capability over the
proactor API, which mostly works as you expect.
I would remind folks of the following Windows-isms compared to POSIX:
Windows was late to the tcp/ip party (championing LAN Manager) and 3rd
parties provided tcp/ip stacks for a l
On Thu, 2015-02-26 at 15:09 -0500, Rafael Schloming wrote:
> ...
> It sounds like one way or another we need at least some design changes. I
> don't think it's workable to have overlapping/close but distinct semantics
> for the API on different platforms (e.g. you can move sockets on one
> platform
On Wed, Feb 25, 2015 at 9:23 PM, Cliff Jansen wrote:
> Two usage cases, very desirable in Proton, happen to be mostly trivial
> on POSIX but mostly non-trivial on Windows: multi-threading and
> external loops. Proton io and selector classes are POSIX-y in look
> and feel, but IO completion ports
Two usage cases, very desirable in Proton, happen to be mostly trivial
on POSIX but mostly non-trivial on Windows: multi-threading and
external loops. Proton io and selector classes are POSIX-y in look
and feel, but IO completion ports are very different and can mimic the
POSIX functionality only
Maybe my head is just thick today, but even staring at the docs a couple
times and reading through what you have below, I can't say I quite
understand what you're going for. What are the actual constraints for the
windows APIs and what is the heavyweight stuff pn_io_t is doing?
--Rafael
On Wed, F
On Wed, Feb 25, 2015 at 12:48 PM, Ted Ross wrote:
>
>
> On 02/25/2015 11:52 AM, Rafael Schloming wrote:
>
>> On Wed, Feb 25, 2015 at 10:49 AM, Ted Ross wrote:
>>
>> Would it be safe to assume that any operations on driver->io are not
>>> thread safe?
>>>
>>> Dispatch is a multi-threaded applica
A pn_io_t is heavyweight in Windows, because it has an opposite usage
pattern and moves a lot of kernel stuff into user space compared to
POSIX.
The quoted documentation was my attempt to capture the Dispatch usage
pattern, which I assumed would be typical of an application trying to
spread proton
On 02/25/2015 11:52 AM, Rafael Schloming wrote:
On Wed, Feb 25, 2015 at 10:49 AM, Ted Ross wrote:
Would it be safe to assume that any operations on driver->io are not
thread safe?
Dispatch is a multi-threaded application. It looks to me as though
io->error is a resource shared across the t
On Wed, Feb 25, 2015 at 10:49 AM, Ted Ross wrote:
> Would it be safe to assume that any operations on driver->io are not
> thread safe?
>
> Dispatch is a multi-threaded application. It looks to me as though
> io->error is a resource shared across the threads in an unsafe way.
>
Interesting... s
Would it be safe to assume that any operations on driver->io are not
thread safe?
Dispatch is a multi-threaded application. It looks to me as though
io->error is a resource shared across the threads in an unsafe way.
-Ted
On 02/25/2015 08:55 AM, Rafael Schloming wrote:
This isn't necessari
On Wed, Feb 25, 2015 at 9:53 AM, Alan Conway wrote:
> On Wed, 2015-02-25 at 09:04 -0500, Michael Goulish wrote:
> > Good point! I'm afraid it will take me the rest of my life
> > to reproduce under valgrind .. but ... I'll see what I can do
>
> Try this in your environment:
> export MALLOC_
On Wed, 2015-02-25 at 09:04 -0500, Michael Goulish wrote:
> Good point! I'm afraid it will take me the rest of my life
> to reproduce under valgrind .. but ... I'll see what I can do
Try this in your environment:
export MALLOC_PERTURB_=66
That will cause malloc to immediately fill freed memo
Good point! I'm afraid it will take me the rest of my life
to reproduce under valgrind .. but ... I'll see what I can do
In the meantime -- I'm not sure what to do with a Jira if the
provenance is in doubt...
- Original Message -
> This isn't necessarily a proton bug. Nothing in th
This isn't necessarily a proton bug. Nothing in the referenced checkin
actually touches the logic around allocating/freeing error strings, it
merely causes pn_send/pn_recv to make use of pn_io_t's pn_error_t where
previously it threw away the error information. This would suggest that
there is perh
...but if not, somebody please feel free to correct me.
The Jira that I just created -- PROTON-826 -- is for a
bug I found with my topology testing of the Dispatch Router,
in which I repeatedly kill and restart a router and make
sure that the router network comes back to the same topology
that
15 matches
Mail list logo
