[Varnish] #840: Varnish on Cygwin-Windows Platform

Jorge Díaz jdzstz at gmail.com
Mon Jan 10 15:34:10 CET 2011

In my opinion, the intrusiveness of patch I have posted is very
limited. Please tell me which of the changes do you think is very
intrusive and what do you think is ok, I send you a little explanation
about my changes.

*  configure.ac and Makefile.am  :  The big changes are applied in
"configure.ac" and all changes are conditional. only are applied if
platform is "cygwin". The rest of platforms ignore new variables or
modifications.  Most of the modifications in Makefile are need because
windows EXE and DLL link process is made in diferent way that linux
ELF format and need some parameters that are setted in configure.ac.
*  bin/varnishd/mgt_vcc.c   :   there is a modification in cygwin to
test if we can use "/bin/sh" or windows "cmd.exe" this allows us to
use windows shell instead cygwin bash.
*  lib/libvarnish/time.c  :   if whe dont have defined
CLOCK_MONOTONIC, we undefine HAVE_CLOCK_GETTIME because has no sense
to use HAVE_CLOCK_GETTIME  code if we do not have a clock monotonic,
as it ocurrs in cygwin.
*  lib/libvarnish/vin.c  :  allow windows paths: c:/path , c:\path or
\\machine\path in varnish dir parameter.
*  lib/libvmod_std/vmod_std.c  : ugly fix to drand48 for cygwin. I
think it can be removed because it will work ok in future cygwin 1.7.8
*  bin/varnishtest/vtc_server.c  :  in process shutdown, the server
thread can be blocked in "accept" function.
          -  Linux has no problem with it, if thread receives
pthread_cancel / pthread_join, the "accept" is unblocked and thread
ends OK.
          -  In Windows, "accept" only is unblocked if a signal is
receved, so the solution is to send a signal to thread with
pthread_kill before making the pthread_join. The signal does nothing.

*  bin/varnishtest/tests/b00015.vtc  and v00009.vtc :
About "connection: close" that I have added in two tests, the reason
is that they have a problematic behaviour in windows:
  1)  varnishd process makes a TCP connection to the mockup web server process.
  2)  the mockup web server returns some contents, as configured in "vtc" file
  3)  if varnishd doesnot receive "connection: close" the TCP
connection is mantained forever, until varnishd process stops
  4)  Inside test, web server  (server s1) is stoped and started
again, and try binding the same port at start
  5)  in linux there is no problem with port reusing, but in windows
there is a problem with "Bind: Address Already in Use" because windows
winsock implementation does not allow reusing this port if the client
process (varnishd) keeps port open in the same machine. ( If client is
in different machine, there is no problem )

If we says to varnisd not to keep opened the connection, the test run fine.

2011/1/10 Varnish <varnish-bugs at varnish-cache.org>:
> #840: Varnish on Cygwin-Windows Platform
> -------------------------+--------------------------------------------------
>  Reporter:  jdzst       |        Type:  enhancement
>    Status:  closed      |    Priority:  normal
>  Milestone:              |   Component:  build
>   Version:  trunk       |    Severity:  normal
> Resolution:  worksforme  |    Keywords:  cygwin, windows
> -------------------------+--------------------------------------------------
> Changes (by phk):
>  * status:  new => closed
>  * resolution:  => worksforme
> Comment:
>  I've looked over your patches, but still find they contain a fair bit too
>  much unwanted stuff, for instance all the "connection: close" in the
>  testcases, (what's up with that ?)
>  As I think I said earlier, we are not likely to see a windows port of
>  Varnish make it past Tier-C status (http://www.varnish-
>  cache.org/docs/trunk/phk/platforms.html) so the intrusiveness of the
>  patches we are willing to entertain is very limited.
>  I would suggest you create a wiki-page for the cygwin port instead of
>  using tickets, until such time as we see that the windows port has a
>  relevance and we have a patch-set we can agree on.
>  In general we do not use tickets for feature-requests, but only for bugs.
> --
> Ticket URL: <http://www.varnish-cache.org/trac/ticket/840#comment:1>
> Varnish <http://varnish-cache.org/>
> The Varnish HTTP Accelerator

More information about the varnish-bugs mailing list