asio-users Mailing List for asio C++ library (Page 259)
Brought to you by:
chris_kohlhoff
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(6) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
|
Mar
(1) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(7) |
Nov
(8) |
Dec
(11) |
2006 |
Jan
(11) |
Feb
(14) |
Mar
(8) |
Apr
(3) |
May
(27) |
Jun
(15) |
Jul
(43) |
Aug
(64) |
Sep
(19) |
Oct
(44) |
Nov
(69) |
Dec
(82) |
2007 |
Jan
(79) |
Feb
(153) |
Mar
(169) |
Apr
(148) |
May
(181) |
Jun
(114) |
Jul
(152) |
Aug
(104) |
Sep
(77) |
Oct
(128) |
Nov
(185) |
Dec
(215) |
2008 |
Jan
(100) |
Feb
(116) |
Mar
(115) |
Apr
(74) |
May
(152) |
Jun
(107) |
Jul
(117) |
Aug
(115) |
Sep
(141) |
Oct
(75) |
Nov
(31) |
Dec
(47) |
2009 |
Jan
(51) |
Feb
(65) |
Mar
(54) |
Apr
(60) |
May
(6) |
Jun
(107) |
Jul
(82) |
Aug
(133) |
Sep
(144) |
Oct
(11) |
Nov
(54) |
Dec
(26) |
2010 |
Jan
(30) |
Feb
(17) |
Mar
(93) |
Apr
(47) |
May
(93) |
Jun
(73) |
Jul
(32) |
Aug
(60) |
Sep
(59) |
Oct
(58) |
Nov
(71) |
Dec
(28) |
2011 |
Jan
(58) |
Feb
(65) |
Mar
(38) |
Apr
(83) |
May
(45) |
Jun
(70) |
Jul
(71) |
Aug
(7) |
Sep
(33) |
Oct
(65) |
Nov
(33) |
Dec
(16) |
2012 |
Jan
(13) |
Feb
(32) |
Mar
(30) |
Apr
(67) |
May
(57) |
Jun
(59) |
Jul
(8) |
Aug
(61) |
Sep
(48) |
Oct
(23) |
Nov
(29) |
Dec
(8) |
2013 |
Jan
(37) |
Feb
(20) |
Mar
(11) |
Apr
(11) |
May
(9) |
Jun
(26) |
Jul
(6) |
Aug
(18) |
Sep
(7) |
Oct
(29) |
Nov
(2) |
Dec
(17) |
2014 |
Jan
(11) |
Feb
(12) |
Mar
(6) |
Apr
(26) |
May
(17) |
Jun
(12) |
Jul
(12) |
Aug
|
Sep
(6) |
Oct
(3) |
Nov
|
Dec
(7) |
2015 |
Jan
(3) |
Feb
(3) |
Mar
(7) |
Apr
(23) |
May
|
Jun
(1) |
Jul
(2) |
Aug
(33) |
Sep
(16) |
Oct
(2) |
Nov
(2) |
Dec
(13) |
2016 |
Jan
(7) |
Feb
(22) |
Mar
(11) |
Apr
|
May
(10) |
Jun
(2) |
Jul
(3) |
Aug
(2) |
Sep
(1) |
Oct
(29) |
Nov
(3) |
Dec
(21) |
2017 |
Jan
(4) |
Feb
(31) |
Mar
(8) |
Apr
(4) |
May
(1) |
Jun
(4) |
Jul
(32) |
Aug
(28) |
Sep
(2) |
Oct
(11) |
Nov
(1) |
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(10) |
Oct
|
Nov
(4) |
Dec
(20) |
2019 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
2020 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
(11) |
Aug
(2) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
2022 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
2023 |
Jan
(3) |
Feb
|
Mar
(5) |
Apr
(3) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
2024 |
Jan
|
Feb
(3) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(6) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: Arvid N. <c9...@cs...> - 2006-03-05 15:52:44
|
basic_socket.hpp:799 looks like this: template <typename Error_Handler> endpoint_type remote_endpoint(Error_Handler error_handler) const { this->service.remote_endpoint(this->implementation, error_handler); } and I get a warning with GCC 3.3 (Apple): ../../asio/include/asio/basic_socket.hpp:802: warning: no return statement in function returning non-void ../../asio/include/asio/basic_socket.hpp:802: warning: control reaches end of non-void function I asssume there's supposed to be a return statement there. regards. -- Arvid Norberg |
From: jose <jj...@ya...> - 2006-03-01 14:20:17
|
Hi Chris, I am either doing something stupid or the problem is with the updated FC4 distro (updated using yum update) I get the same problem in these two platforms: x86 - updated FC4 - g++ 4.0.2 - boost-cvs - asio cvs x86_64 - updated FC4 - g++ 4.0.2 - boost 1.33.0 - asio cvs Regards Jose --- jose <jj...@ya...> escribió: > > --- Christopher Kohlhoff <ch...@ko...> > escribió: > > > Well, I don't think it's a 64-bit problem or > > anything (assuming you're > > still trying it on the same box as before) because > I > > just tried the SSL > > example on an AMD64 box running FC3 and it works > > fine. > > > > What exactly do you mean by fail? Is it hanging > and > > unable to connect? > > That seems to be what the strace output suggests. > If > > it is hanging, > > what is the call stack at the time? > > It is not aborting, the strace stops at the select > call > > > What happens if you try "127.0.0.1" as the target > > address? > > the same happens > > I am using x86_64 g++ 4.0.2 > I will also try on a x86 g++ 4.0.2 box > > Let me know if you need testing help on these 2 > platforms, as I will gladly dedicate time to it > > Regards > Jose > > > > ______________________________________________ > LLama Gratis a cualquier PC del Mundo. > Llamadas a fijos y móviles desde 1 céntimo por > minuto. > http://es.voice.yahoo.com > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a > groundbreaking scripting language > that extends applications into web and mobile media. > Attend the live webcast > and join the prime developer group breaking into > this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > asio-users mailing list > asi...@li... > https://lists.sourceforge.net/lists/listinfo/asio-users > ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com |
From: jose <jj...@ya...> - 2006-03-01 13:29:40
|
--- Christopher Kohlhoff <ch...@ko...> escribió: > Well, I don't think it's a 64-bit problem or > anything (assuming you're > still trying it on the same box as before) because I > just tried the SSL > example on an AMD64 box running FC3 and it works > fine. > > What exactly do you mean by fail? Is it hanging and > unable to connect? > That seems to be what the strace output suggests. If > it is hanging, > what is the call stack at the time? It is not aborting, the strace stops at the select call > What happens if you try "127.0.0.1" as the target > address? the same happens I am using x86_64 g++ 4.0.2 I will also try on a x86 g++ 4.0.2 box Let me know if you need testing help on these 2 platforms, as I will gladly dedicate time to it Regards Jose ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com |
From: Christopher K. <ch...@ko...> - 2006-03-01 12:23:58
|
--- jose <jj...@ya...> wrote: > Hi Chris, > > I am running the ssl client test and it fails (below > is the strace output) > > ./server 90 > and then > client local-ip 90 > > Any ideas ? Well, I don't think it's a 64-bit problem or anything (assuming you're still trying it on the same box as before) because I just tried the SSL example on an AMD64 box running FC3 and it works fine. What exactly do you mean by fail? Is it hanging and unable to connect? That seems to be what the strace output suggests. If it is hanging, what is the call stack at the time? What happens if you try "127.0.0.1" as the target address? Cheers, Chris |
From: jose <jj...@ya...> - 2006-03-01 10:20:21
|
Hi Chris, I am running the ssl client test and it fails (below is the strace output) ./server 90 and then client local-ip 90 Any ideas ? Thanks Jose ----- open("ca.pem", O_RDONLY) = 7 fstat(7, {st_mode=S_IFREG|0644, st_size=1680, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaaaaaac000 read(7, "-----BEGIN CERTIFICATE-----\nMIIB"..., 4096) = 1680 read(7, "", 4096) = 0 close(7) = 0 munmap(0x2aaaaaaac000, 4096) = 0 socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 7 ioctl(7, FIONBIO, [1]) = 0 connect(7, {sa_family=AF_INET, sin_port=htons(90), sin_addr=inet_addr("192.168.1.20")}, 16) = -1 EINPROGRESS (Operation now in progress) write(4, "\0", 1) = 1 select(7, [3], [], [], NULL) = 1 (in [3]) rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0 read(3, "\0", 1024) = 1 open("/etc/localtime", O_RDONLY) = 8 fstat(8, {st_mode=S_IFREG|0644, st_size=946, ...}) = 0 fstat(8, {st_mode=S_IFREG|0644, st_size=946, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaaaaaac000 read(8, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\10"..., 4096) = 946 close(8) = 0 munmap(0x2aaaaaaac000, 4096) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 select(7, [3], [], [], NULL ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com |
From: jose <jj...@ya...> - 2006-03-01 09:54:58
|
hi Chris, I've upgraded to 4.0.2 (from 4.0.1) and the warning goes away Thanks --- Christopher Kohlhoff <ch...@ko...> escribió: > Hi Jose, > > --- jose <jj...@ya...> wrote: > > > Hi Chris, > > > > Any idea why I get this warning when using asio > cvs ? > > I am running Linux FC4 x86_64 > > > > Regards and thanks > > Jose > > > > /d2/dev/boost/boost/date_time/time_duration.hpp: > In > > member function 'timeval* > > asio::detail::select_reactor<Own_Thread, > > Allocator>::get_timeout(timeval&) [with bool > > Own_Thread = false, Allocator = > > std::allocator<void>]': > > > /d2/dev/boost/boost/date_time/time_duration.hpp:58: > > warning: control may reach end of non-void > function > > 'static typename frac_sec_type::int_type > > > boost::date_time::time_resolution_traits<frac_sec_type, > > res, resolution_adjust, frac_digits, > > v_type>::to_tick_count(v_type, v_type, v_type, > > typename frac_sec_type::int_type) [with > frac_sec_type > > = > > > boost::date_time::time_resolution_traits_adapted64_impl, > > boost::date_time::time_resolutions res = micro, > > typename frac_sec_type::int_type resolution_adjust > = > > 1000000, short unsigned int frac_digits = 6u, > v_type = > > int32_t]' being inlined > > Very strange. This warning is about a function in > the Boost.Date-Time > library, and I don't see how (in either 1.33.0 or > 1.33.1) it contains > any control paths that don't return. What version of > g++ are you using? > > Cheers, > Chris > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a > groundbreaking scripting language > that extends applications into web and mobile media. > Attend the live webcast > and join the prime developer group breaking into > this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > asio-users mailing list > asi...@li... > https://lists.sourceforge.net/lists/listinfo/asio-users > ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com |
From: jose <jj...@ya...> - 2006-03-01 00:29:29
|
hi chris, g++ 4.0.1. I get the warning with either boost 1.33 or boost cvs Let me know anything I should look at regards jose --- Christopher Kohlhoff <ch...@ko...> escribió: > Hi Jose, > > --- jose <jj...@ya...> wrote: > > > Hi Chris, > > > > Any idea why I get this warning when using asio > cvs ? > > I am running Linux FC4 x86_64 > > > > Regards and thanks > > Jose > > > > /d2/dev/boost/boost/date_time/time_duration.hpp: > In > > member function 'timeval* > > asio::detail::select_reactor<Own_Thread, > > Allocator>::get_timeout(timeval&) [with bool > > Own_Thread = false, Allocator = > > std::allocator<void>]': > > > /d2/dev/boost/boost/date_time/time_duration.hpp:58: > > warning: control may reach end of non-void > function > > 'static typename frac_sec_type::int_type > > > boost::date_time::time_resolution_traits<frac_sec_type, > > res, resolution_adjust, frac_digits, > > v_type>::to_tick_count(v_type, v_type, v_type, > > typename frac_sec_type::int_type) [with > frac_sec_type > > = > > > boost::date_time::time_resolution_traits_adapted64_impl, > > boost::date_time::time_resolutions res = micro, > > typename frac_sec_type::int_type resolution_adjust > = > > 1000000, short unsigned int frac_digits = 6u, > v_type = > > int32_t]' being inlined > > Very strange. This warning is about a function in > the Boost.Date-Time > library, and I don't see how (in either 1.33.0 or > 1.33.1) it contains > any control paths that don't return. What version of > g++ are you using? > > Cheers, > Chris > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a > groundbreaking scripting language > that extends applications into web and mobile media. > Attend the live webcast > and join the prime developer group breaking into > this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > asio-users mailing list > asi...@li... > https://lists.sourceforge.net/lists/listinfo/asio-users > ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com |
From: Christopher K. <ch...@ko...> - 2006-02-28 23:50:25
|
Hi Jose, --- jose <jj...@ya...> wrote: > Hi Chris, > > Any idea why I get this warning when using asio cvs ? > I am running Linux FC4 x86_64 > > Regards and thanks > Jose > > /d2/dev/boost/boost/date_time/time_duration.hpp: In > member function 'timeval* > asio::detail::select_reactor<Own_Thread, > Allocator>::get_timeout(timeval&) [with bool > Own_Thread = false, Allocator = > std::allocator<void>]': > /d2/dev/boost/boost/date_time/time_duration.hpp:58: > warning: control may reach end of non-void function > 'static typename frac_sec_type::int_type > boost::date_time::time_resolution_traits<frac_sec_type, > res, resolution_adjust, frac_digits, > v_type>::to_tick_count(v_type, v_type, v_type, > typename frac_sec_type::int_type) [with frac_sec_type > = > boost::date_time::time_resolution_traits_adapted64_impl, > boost::date_time::time_resolutions res = micro, > typename frac_sec_type::int_type resolution_adjust = > 1000000, short unsigned int frac_digits = 6u, v_type = > int32_t]' being inlined Very strange. This warning is about a function in the Boost.Date-Time library, and I don't see how (in either 1.33.0 or 1.33.1) it contains any control paths that don't return. What version of g++ are you using? Cheers, Chris |
From: jose <jj...@ya...> - 2006-02-28 22:36:44
|
Hi Chris, Any idea why I get this warning when using asio cvs ? I am running Linux FC4 x86_64 Regards and thanks Jose /d2/dev/boost/boost/date_time/time_duration.hpp: In member function 'timeval* asio::detail::select_reactor<Own_Thread, Allocator>::get_timeout(timeval&) [with bool Own_Thread = false, Allocator = std::allocator<void>]': /d2/dev/boost/boost/date_time/time_duration.hpp:58: warning: control may reach end of non-void function 'static typename frac_sec_type::int_type boost::date_time::time_resolution_traits<frac_sec_type, res, resolution_adjust, frac_digits, v_type>::to_tick_count(v_type, v_type, v_type, typename frac_sec_type::int_type) [with frac_sec_type = boost::date_time::time_resolution_traits_adapted64_impl, boost::date_time::time_resolutions res = micro, typename frac_sec_type::int_type resolution_adjust = 1000000, short unsigned int frac_digits = 6u, v_type = int32_t]' being inlined ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com |
From: Christopher K. <ch...@ko...> - 2006-02-28 10:26:04
|
Hi Boris, --- godot <mo...@gm...> wrote: > While stepping through your select function I noticed: on first call > "timeout" is set to 1 second, on all following calls the "timeout" > pointer is 0. > So, > 1. your code change does not apply and > 2. ::select will return immediatly indeed, as you suspected Actually if the timeout pointer is 0 then select is supposed to block indefinitely, but in this particular case is returning because the "socket_select_interrupter" is being made readable. Unfortunately, stepping through the code doesn't seem to help in debugging this issue, because long pauses as you step between function calls change the behaviour of the timer :( What I did was insert a few printfs into the asio code to see what was going on with the test program you sent. Can you try the following changes (i.e. with the earlier change that i suggested disabled) to see what you get: Index: select_reactor.hpp =================================================================== RCS file: /cvsroot/asio/asio/include/asio/detail/select_reactor.hpp,v retrieving revision 1.37 diff -u -u -r1.37 select_reactor.hpp --- select_reactor.hpp 2 Feb 2006 07:02:01 -0000 1.37 +++ select_reactor.hpp 28 Feb 2006 10:16:32 -0000 @@ -264,6 +264,7 @@ read_op_queue_.dispatch_cancellations(); write_op_queue_.dispatch_cancellations(); } + printf("Dispatching timers\n"); timer_queue_.dispatch_timers( boost::posix_time::microsec_clock::universal_time()); Index: socket_ops.hpp =================================================================== RCS file: /cvsroot/asio/asio/include/asio/detail/socket_ops.hpp,v retrieving revision 1.36 diff -u -u -r1.36 socket_ops.hpp --- socket_ops.hpp 23 Feb 2006 12:31:08 -0000 1.36 +++ socket_ops.hpp 28 Feb 2006 10:22:54 -0000 @@ -466,8 +466,17 @@ ::Sleep(milliseconds); return 0; } + if (timeout) + printf("select timeout = { %d, %d }\n", timeout->tv_sec, timeout->tv_usec); + else + printf("select timeout = NULL\n"); + //if (timeout && timeout->tv_sec == 0 + // && timeout->tv_usec > 0 && timeout->tv_usec < 10000) + // timeout->tv_usec = 10000; #endif // defined(BOOST_WINDOWS) - return error_wrapper(::select(nfds, readfds, writefds, exceptfds, timeout)); + int r = error_wrapper(::select(nfds, readfds, writefds, exceptfds, timeout)); + printf("select result = %d\n", r); + return r; } You may need to pipe the output to a file so that the printfs don't change the timing too much. When I run it, sometimes I see things like the following in the output: restart select result = 1 Dispatching timers select timeout = { 0, 992800 } select result = 0 Dispatching timers select timeout = { 0, 1374 } select result = 0 Dispatching timers select timeout = { 0, 1374 } select result = 0 Dispatching timers select timeout = { 0, 1374 } select result = 0 Dispatching timers select timeout = { 0, 1374 } select result = 0 Dispatching timers select timeout = NULL restart which shows the select call returning immediately in spite of the timeout value. Cheers, Chris |
From: godot <mo...@gm...> - 2006-02-28 08:47:29
|
asi...@li... schrieb: > I suspect that the problem is due to the timeout granularity on the > Windows implementation of select(). It appears that a very short > timeout (<10 milliseconds?) makes select() return immediately. If the > current time is very close to the timer expiry, this immediate return > might cause the select reactor to spin (thus accounting for the CPU > usage you observe) until the timer expiry is reached. > > Can you please try the following change to see if it makes a > difference: > > RCS file: /cvsroot/asio/asio/include/asio/detail/socket_ops.hpp,v > retrieving revision 1.36 > diff -u -r1.36 socket_ops.hpp > --- include/asio/detail/socket_ops.hpp 23 Feb 2006 12:31:08 -0000 > 1.36 > +++ include/asio/detail/socket_ops.hpp 27 Feb 2006 11:38:06 -0000 > @@ -466,6 +466,9 @@ > ::Sleep(milliseconds); > return 0; > } > + if (timeout && timeout->tv_sec == 0 > + && timeout->tv_usec > 0 && timeout->tv_usec < 10000) > + timeout->tv_usec = 10000; > #endif // defined(BOOST_WINDOWS) > return error_wrapper(::select(nfds, readfds, writefds, exceptfds, > timeout)); > } > Hi Chris, I changed the socket_ops.hpp and recompiled but it makes no difference. While stepping through your select function I noticed: on first call "timeout" is set to 1 second, on all following calls the "timeout" pointer is 0. So, 1. your code change does not apply and 2. ::select will return immediatly indeed, as you suspected Maybe this might help, Regards, Boris PS: Thanks for your great work, I'm using asio extensivly in gui apps and I hope asio will be accepted to boost. |
From: Christopher K. <ch...@ko...> - 2006-02-27 11:40:43
|
Hi Boris, --- godot <mo...@gm...> wrote: > Hi, > I have a question concerning the cpu usage of the > asio::deadline_timer. > Consider this sample code: > > void restart( asio::deadline_timer* t ) > { > std::cout << "restart" << std::endl; > t->expires_at( t->expires_at() + boost::posix_time::seconds( 1 )); > t->async_wait( boost::bind( restart, t )); > } > > int main() > { > asio::demuxer d; > asio::deadline_timer t(d, boost::posix_time::seconds( 1 )); > t.async_wait( boost::bind( restart, &t )); > d.run(); > return 0; > } > > > I'm using asio 0.3.6. and vc.net. It consumes 2% processor time while > running when compiled in release mode, quite a lot for a mostly idle > application, I think. Is it because the timer is so "fine-grained" in > time? If I do not need a high performance timer, is it possible to > finetune the timer setting, so that my application does not keeps the > processor that busy? I suspect that the problem is due to the timeout granularity on the Windows implementation of select(). It appears that a very short timeout (<10 milliseconds?) makes select() return immediately. If the current time is very close to the timer expiry, this immediate return might cause the select reactor to spin (thus accounting for the CPU usage you observe) until the timer expiry is reached. Can you please try the following change to see if it makes a difference: RCS file: /cvsroot/asio/asio/include/asio/detail/socket_ops.hpp,v retrieving revision 1.36 diff -u -r1.36 socket_ops.hpp --- include/asio/detail/socket_ops.hpp 23 Feb 2006 12:31:08 -0000 1.36 +++ include/asio/detail/socket_ops.hpp 27 Feb 2006 11:38:06 -0000 @@ -466,6 +466,9 @@ ::Sleep(milliseconds); return 0; } + if (timeout && timeout->tv_sec == 0 + && timeout->tv_usec > 0 && timeout->tv_usec < 10000) + timeout->tv_usec = 10000; #endif // defined(BOOST_WINDOWS) return error_wrapper(::select(nfds, readfds, writefds, exceptfds, timeout)); } I'm not sure if this is the best solution, but at least it will help determine if this is in fact the cause of the bug you observe. Cheers, Chris |
From: godot <mo...@gm...> - 2006-02-27 10:18:41
|
Hi, I have a question concerning the cpu usage of the asio::deadline_timer. Consider this sample code: void restart( asio::deadline_timer* t ) { std::cout << "restart" << std::endl; t->expires_at( t->expires_at() + boost::posix_time::seconds( 1 )); t->async_wait( boost::bind( restart, t )); } int main() { asio::demuxer d; asio::deadline_timer t(d, boost::posix_time::seconds( 1 )); t.async_wait( boost::bind( restart, &t )); d.run(); return 0; } I'm using asio 0.3.6. and vc.net. It consumes 2% processor time while running when compiled in release mode, quite a lot for a mostly idle application, I think. Is it because the timer is so "fine-grained" in time? If I do not need a high performance timer, is it possible to finetune the timer setting, so that my application does not keeps the processor that busy? Thx, Boris |
From: Christopher K. <ch...@ko...> - 2006-02-26 21:22:55
|
Hi, --- Moo...@ma... wrote: > Hi, > I am trying to build a project (libtorrent) which uses asio with > VC71. Everything compiles ok but the linking fails. > > Because of the constructor/destructor of the auto_work struct in > win_iocp_service.hpp. It seems I have reintroduced the bug as described in: http://sourceforge.net/tracker/index.php?func=detail&aid=1329446&group_id=122478&atid=694037 > I think this is a compiler problem, however is there a work around > for that? The code just needs to be changed so that the class is not nested inside a function definition. > Maybe you can explain the purpose of this structure. This particular class is just to make sure the code is exception-safe, i.e. ensure various values are modified on function exit (regardless of whether an exception is thrown or not). I'll fix it in CVS - you should see the modified file show up in a few hours. Cheers, Chris |
From: <Moo...@ma...> - 2006-02-26 16:46:17
|
Hi, I am trying to build a project (libtorrent) which uses asio with VC71. Everything compiles ok but the linking fails. Because of the constructor/destructor of the auto_work struct in win_iocp_service.hpp. linker msgs: session.obj : warning LNK4006: "public: __thiscall `public: void __thiscall asio::detail::win_iocp_io_service<class std::allocator<void> >::run(void)'::`9'::auto_work::auto_work(class asio::detail::win_iocp_io_service<class std::allocator<void> > &)" (??0auto_work@?8??run@?$win_iocp_io_service@V?$allocator@X@std@@@detail @asio@@QAEXXZ@QAE@AAV234@@Z) already defined in http_tracker_connection.obj; second definition ignored session.obj : warning LNK4006: "public: __thiscall `public: void __thiscall asio::detail::win_iocp_io_service<class std::allocator<void> >::run(void)'::`9'::auto_work::~auto_work(void)" (??1auto_work@?8??run@?$win_iocp_io_service@V?$allocator@X@std@@@detail @asio@@QAEXXZ@QAE@XZ) already defined in http_tracker_connection.obj; second definition ignored udp_tracker_connection.obj : warning LNK4006: "public: __thiscall `public: void __thiscall asio::detail::win_iocp_io_service<class std::allocator<void> >::run(void)'::`9'::auto_work::auto_work(class asio::detail::win_iocp_io_service<class std::allocator<void> > &)" (??0auto_work@?8??run@?$win_iocp_io_service@V?$allocator@X@std@@@detail @asio@@QAEXXZ@QAE@AAV234@@Z) already defined in http_tracker_connection.obj; second definition ignored udp_tracker_connection.obj : warning LNK4006: "public: __thiscall `public: void __thiscall asio::detail::win_iocp_io_service<class std::allocator<void> >::run(void)'::`9'::auto_work::~auto_work(void)" (??1auto_work@?8??run@?$win_iocp_io_service@V?$allocator@X@std@@@detail @asio@@QAEXXZ@QAE@XZ) already defined in http_tracker_connection.obj; second definition ignored I think this is a compiler problem, however is there a work around for that? Maybe you can explain the purpose of this structure. Thx MassaRoddel |
From: Christopher K. <ch...@ko...> - 2006-02-26 12:53:22
|
Hi Jeffrey, --- Jeffrey Chang <jef...@gm...> wrote: > I'm using asio::deadline_timer to implement a dedicate timer > thread. It works ok, except for a memory leak problem > (reported by Valgrind) when demuxer::post() is called after > demuxer::run() returns. As of 0.3.6, it is the application's responsibility to call demuxer::run() until there is no work left to do. Since your app is not calling demuxer::run() after calling demuxer::post(), it is not fulfilling that responsibility, hence the leak. For convenience, I'm looking at cleaning up undelivered handlers in the demuxer's destructor, but that's for a future version. For now, to implement a clean shutdown you should cancel all timers and wait for the demuxer::run() call to return normally. It will return once all handlers have been delivered. Cheers, Chris |
From: Jeffrey C. <jef...@gm...> - 2006-02-22 03:55:50
|
Hi, I'm using asio::deadline_timer to implement a dedicate timer thread. It works ok, except for a memory leak problem (reported by Valgrind) when demuxer::post() is called after demuxer::run() returns. Here's the stack trace that shows a "handler_wrapper<Handle>" object is created without corresponding deletion: .... asio::basic_demuxer<Demuxer_Service>::post(Handler) (basic_demuxer.hpp:174), which calls .... asio::demuxer_service<Allocator>::post(Handler) (demuxer_service.hpp:124), which calls 211 template <typename Handler> 212 void post(Handler handler) 213 { 214 boost::asio::detail::mutex::scoped_lock lock(mutex_); 215 216 // Add the handler to the end of the queue. 217 handler_base* h =3D new handler_wrapper<Handler>(handler); 218 if (handler_queue_end_) 219 { 220 handler_queue_end_->next_ =3D h; 221 handler_queue_end_ =3D h; 222 } 223 else 224 { 225 handler_queue_ =3D handler_queue_end_ =3D h; 226 } 227 228 // An undelivered handler is treated as unfinished work. 229 ++outstanding_work_; 230 231 // Wake up a thread to execute the handler. 232 if (!interrupt_one_idle_thread()) 233 interrupt_task(); 234 } It looks like that, if demuxer::run() has finished and there's no thread to be waken up (in Line#231-234) for serving the posted Handler "*h" (created in Line#217), then "*h" is left alone without destruction Is this a bug? I'm using boost-asio-proposal-0.3.6. --- Jeffrey |
From: Arvid N. <c9...@cs...> - 2006-02-20 10:31:24
|
On Feb 20, 2006, at 04:50, Christopher Kohlhoff wrote: > [...] > I see what the problem is - my fault for not testing some changes I > did > thoroughly :) Sorry. > > Please try the following change to > asio/ipv4/detail/host_resolver_service.hpp: > [...] I presume that these are the changes made on cvs as well, and with those it works perfectly. Thanks! regards -- Arvid Norberg |
From: Christopher K. <ch...@ko...> - 2006-02-20 03:50:46
|
Hi Arvid, --- Arvid Norberg <c9...@cs...> wrote: > On Feb 18, 2006, at 19:08, Arvid Norberg wrote: > > I don't experience any problems anymore. Nice work. > > I was a little bit too quick on that conclusion. > > The deadlock is gone. But instead the async_by_name (formerly known > as: async_get_host_by_name) Expect even more changes when I finish adding IPv6 support ;) > always results in an "operation aborted". > The synchronous version works though. > > This worked fine in the cvs version from about 3 weeks ago, but not > in today's version. (This is still MacOS X) I see what the problem is - my fault for not testing some changes I did thoroughly :) Sorry. Please try the following change to asio/ipv4/detail/host_resolver_service.hpp: --- host_resolver_service.hpp 2 Feb 2006 07:02:03 -0000 1.19 +++ host_resolver_service.hpp 20 Feb 2006 03:48:56 -0000 @@ -71,6 +71,7 @@ // as a cancellation token to indicate to the background thread that the // operation has been cancelled. typedef boost::shared_ptr<void> implementation_type; + struct noop_deleter { void operator()(void*) {} }; // Constructor. host_resolver_service(IO_Service& d) @@ -105,6 +106,7 @@ // Construct a new host resolver implementation. void construct(implementation_type& impl) { + impl.reset(static_cast<void*>(0), noop_deleter()); } // Destroy a host resolver implementation. @@ -115,7 +117,7 @@ /// Cancel pending asynchronous operations. void cancel(implementation_type& impl) { - impl.reset(0); + impl.reset(static_cast<void*>(0), noop_deleter()); } Cheers, Chris |
From: Arvid N. <c9...@cs...> - 2006-02-20 01:57:23
|
On Feb 18, 2006, at 19:08, Arvid Norberg wrote: > I don't experience any problems anymore. Nice work. I was a little bit too quick on that conclusion. The deadlock is gone. But instead the async_by_name (formerly known as: async_get_host_by_name) always results in an "operation aborted". The synchronous version works though. This worked fine in the cvs version from about 3 weeks ago, but not in today's version. (This is still MacOS X) thanks. -- Arvid Norberg |
From: Arvid N. <c9...@cs...> - 2006-02-18 18:08:53
|
On Jan 25, 2006, at 07:54, Christopher Kohlhoff wrote: > Hi Arvid, > > --- Arvid Norberg <c9...@cs...> wrote: >> I'm now experiencing a deadlock with the cvs version of asio >> (from a few days ago). It occurs when I have one connection >> receiving data continously and another connection that is >> closed. The connection that is being closed will cause the >> deadlock because the last shared_ptr to the connection object >> (which in turn is holding the tcp::socket) is stored in the >> handler. When the handler is destructed the socket will be >> destructed and closed, and close will lock the demuxer >> service, and deadlock. > > I think I know what the problem is, and I have just committed a > change to CVS to try to fix it. Can you please give it a go and > see what happens. It should show up in the public sourceforge > CVS in about 6 hours. > > I'm planning to rewrite the reactor stuff soon anyway to > eliminate memory allocations, reduce locking time, and generally > improve performance. The kqueue_reactor will be the first to be > rewritten, as I'm using Mac OS X as my main dev platform. I don't experience any problems anymore. Nice work. -- Arvid Norberg |
From: Christopher K. <ch...@ko...> - 2006-01-29 04:02:40
|
Hi Boris, --- godot <mo...@gm...> wrote: > I have a question concerning udp datagram sockets: When the > sender calls async_send_to with a datagram of size N, is it > garanteed for async_receive_from to get the the same size N in > the bytes_transferred parameter of the handler (assuming no > error)? I mean, do I get the datagram in one sweep or do I > have to call async_receive_from in an iterative way? Yes, you do get the whole datagram in a single receive operation, provided the buffer is large enough to hold the datagram. If the buffer is not large enough, the message is truncated and the additional data is lost. As a side note, W. Richard Stevens' Unix Network Programming vol. 1 recommends making the buffer one byte larger than the largest message that your program supports, so that you can detect oversized messages correctly. > When I have a connectionless datagram socket, would it be > possible then to simplify the serialization example and skip > the additional length header parsing? Yep, you could do this. Of course, with UDP your message can get lost and you won't find out about it, so if the serialisation example was implemented using UDP the client would need to have some sort of receive timeout. Cheers, Chris |
From: godot <mo...@gm...> - 2006-01-29 02:00:38
|
I have a question concerning udp datagram sockets: When the sender calls async_send_to with a datagram of size N, is it garanteed for async_receive_from to get the the same size N in the bytes_transferred parameter of the handler (assuming no error)? I mean, do I get the datagram in one sweep or do I have to call async_receive_from in an iterative way? When I have a connectionless datagram socket, would it be possible then to simplify the serialization example and skip the additional length header parsing? Regards, Boris |
From: Arvid N. <c9...@cs...> - 2006-01-25 07:02:12
|
On Jan 25, 2006, at 07:54, Christopher Kohlhoff wrote: > Hi Arvid, > > --- Arvid Norberg <c9...@cs...> wrote: >> I'm now experiencing a deadlock with the cvs version of asio >> (from a few days ago). It occurs when I have one connection >> receiving data continously and another connection that is >> closed. The connection that is being closed will cause the >> deadlock because the last shared_ptr to the connection object >> (which in turn is holding the tcp::socket) is stored in the >> handler. When the handler is destructed the socket will be >> destructed and closed, and close will lock the demuxer >> service, and deadlock. > > I think I know what the problem is, and I have just committed a > change to CVS to try to fix it. Can you please give it a go and > see what happens. It should show up in the public sourceforge > CVS in about 6 hours. > > I'm planning to rewrite the reactor stuff soon anyway to > eliminate memory allocations, reduce locking time, and generally > improve performance. The kqueue_reactor will be the first to be > rewritten, as I'm using Mac OS X as my main dev platform. Ok, great! I will try this as soon as possible. I'll be out of town for the next 3 weeks, so no sooner than that. -- Arvid Norberg |
From: Christopher K. <ch...@ko...> - 2006-01-25 06:54:27
|
Hi Arvid, --- Arvid Norberg <c9...@cs...> wrote: > I'm now experiencing a deadlock with the cvs version of asio > (from a few days ago). It occurs when I have one connection > receiving data continously and another connection that is > closed. The connection that is being closed will cause the > deadlock because the last shared_ptr to the connection object > (which in turn is holding the tcp::socket) is stored in the > handler. When the handler is destructed the socket will be > destructed and closed, and close will lock the demuxer > service, and deadlock. I think I know what the problem is, and I have just committed a change to CVS to try to fix it. Can you please give it a go and see what happens. It should show up in the public sourceforge CVS in about 6 hours. I'm planning to rewrite the reactor stuff soon anyway to eliminate memory allocations, reduce locking time, and generally improve performance. The kqueue_reactor will be the first to be rewritten, as I'm using Mac OS X as my main dev platform. Cheers, Chris |