Re: Squid 3 Windows native port: update on current status

Hi Henrik,

At 01.21 03/01/2005, Henrik Nordstrom wrote:

>On Fri, 31 Dec 2004, Serassio Guido wrote:
>
>>- Full build is OK, on both MinGW and MS Visual Studio 2005 beta 1 (with
>>some minor patches), so I'm ready to dropping out the old MS Visual
>>Studio 6 support.
>
>Excellent!

The transition is now complete, all MS Visual Studio 6 support was dropped.

>>- There are still some critical problem related to FDs handling in the
>>Robert's old refactored IPC code
>>(http://www.squid-cache.org/~robertc/ipc.refactoring.patch) that is
>>already included in the Windows port
>
>Anything we can do to help understanding the problem or how to solve it?

I don't know. The behaviour is different between MinGW and Visual Studio:

On Visual Studio it seems that Windows Handles of files opened with fopen()
(cache.log, for example) are inherited from child process even if the
inheritance was disabled before the child spawn, this cause a deadlock
during write operations of cache.log that hangs Squid.

On MinGW it seems that squid main process opens twice the same log file,
probably a duplicated Windows Handle, and this cause the fail of logs
rotate operation plus some random strange "access denied" error when
writing to the cache and logs.

The original 2.5 source code works fine.

I will try to do a comparative full trace debug between 2.5 and 3.0
startup, hoping to see what is different in 3.0 startup sequence.

>>- I'm working on a new WinAIO DISKIO engine, it builds fine, but I cannot
>>test and debug it for the IPC problems. After the WinAIO development, I
>>will start with a second DISKIO engine: WinDiskThreads.
>
>What I/O model is the WinAIO DISKIO engine using?

Overlapped I/O with aio_read() aio_write() emulation, it's the one to one
port of the old COSS Windows support.

>I would think the optimal model on Windows is overlapped I/O with
>completetion ports rather than threads? But as with POSIX AIO the weak
>link seems to be missing support for async open/close calls..
>
>My gut feeling is that optimal performance on Windows should be seen from
>
> - A not too large pool of threads used for CreateFile / CloseHandle calls.
>
> - All actual I/O done using overlapped I/O with results signalled via a
> completetion port by and to the main thread.

I have already refactored the old awin32 aufs clone based on Windows
threads as WinDiskThreads DISKIO engine.

When both DISKIO engine will be stable, it will be very interesting analyze
how/if to merge they in a single Windows DISKIO engine.

Regards

Guido

-
========================================================
Guido Serassio
Acme Consulting S.r.l. - Microsoft Certified Partner
Via Gorizia, 69 10136 - Torino - ITALY
Tel. : +39.011.3249426 Fax. : +39.011.3293665
Email: guido.serassio@acmeconsulting.it
WWW: http://www.acmeconsulting.it/
Received on Mon Jan 03 2005 - 10:12:40 MST