Re: [Musicpd-dev-team] New event loop implementation
On 2013/12/02 11:12, Denis Krjuchkov de...@crazydev.net wrote: I've added poll based PollGroup implementation: http://git.musicpd.org/cgit/dk/mpd.git/commit/?id=1df426aa5c571d3d88ecb7bed6b8ed9b32c15e32 After quick testing connecting with client and playing http streams work, however I didn't succeed in using http output. I have now fixed the remaining problems (which were not in your code, but in my httpd plugin code), and it appears to work now. I have just removed our GLib implementation of EventLoop. There's no use for it anymore. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] New event loop implementation
On 2013/12/02 11:12, Denis Krjuchkov de...@crazydev.net wrote: I've added poll based PollGroup implementation: http://git.musicpd.org/cgit/dk/mpd.git/commit/?id=1df426aa5c571d3d88ecb7bed6b8ed9b32c15e32 After quick testing connecting with client and playing http streams work, however I didn't succeed in using http output. I think it still could be merged because it's not completely useless and this backend is not activated by default anyway. Agree. We'll figure out the remaining bugs. Merged. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] New event loop implementation
I've added Windows select backend for event loop as well as few fixes. PollGroupEPoll.hxx: add const modifiers where applicable Clock.cxx: provide all arguments for GetProcessTimes event: implement PollGroup based on Windows select configure.ac: code style improvements New backend is enabled by default, I've played with it a bit and it's working for me unlike GLib event loop which is not working at all. -- Denis -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] New event loop implementation
On 2013/11/29 10:40, Denis Krjuchkov de...@crazydev.net wrote: I've added Windows select backend for event loop as well as few fixes. Merged. I like how well the incremental way of doing this works. When you've added the portable poll() implementation, we'll test it, and then we will eventually remove the GLib code. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] New event loop implementation
29.11.2013 16:00, Max Kellermann пишет: Merged. I like how well the incremental way of doing this works. When you've added the portable poll() implementation, we'll test it, and then we will eventually remove the GLib code. Hi Max, I appreciate your help in developing this. I'm wondering is there any plan for GLib removal in particular and tasks for new version in general? I think it would be very convenient to have such list so we can split tasks, discuss implementation details, etc. http://bugs.musicpd.org looks like a suitable place for such things, but as far as understand currently it's used for user feedback and user feature requests. What do you think? -- Denis -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] New event loop implementation
On 2013/11/29 19:18, Denis Krjuchkov de...@crazydev.net wrote: I'm wondering is there any plan for GLib removal in particular and tasks for new version in general? No, there is no grand plan. Things just happen whenever somebody chooses to spend time on the code ;-) There are quite a few ideas I have, and most of the time, I prepare for them by refactoring code. For example, the GLib removal will lead to the Android port. Multi-player support is one rather large feature (multiple players inside one MPD process), and during 0.18 development, there were many preparations for this (struct Partition), but this will take a long time. I think it would be very convenient to have such list so we can split tasks, discuss implementation details, etc. http://bugs.musicpd.org looks like a suitable place for such things, but as far as understand currently it's used for user feedback and user feature requests. What do you think? Yes, why not. Tell me your Mantis user name, and I'll raise your privileges. Then you can manage all the tickets you'd like to do. Max -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] New event loop implementation
30.11.2013 0:27, Max Kellermann пишет: No, there is no grand plan. Things just happen whenever somebody chooses to spend time on the code ;-) I didn't mean plan as a schedule for any specific version. I meant plan as a list of tasks that anybody could pick and implement if they want to help project. There are quite a few ideas I have, and most of the time, I prepare for them by refactoring code. For example, the GLib removal will lead to the Android port. Multi-player support is one rather large feature (multiple players inside one MPD process), and during 0.18 development, there were many preparations for this (struct Partition), but this will take a long time. This looks very interesting. Especially Android port. I think it would be useful to have a list of things to refactor, if you have enought spare time for documenting that. Yes, why not. Tell me your Mantis user name, and I'll raise your privileges. Then you can manage all the tickets you'd like to do. My login is denis. -- Denis -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] New event loop implementation
On 2013/11/28 16:30, Denis Krjuchkov de...@crazydev.net wrote: I've added one more patch. This introduces generic poll API as well as implementation for epoll. Merged. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] New event loop implementation
I've made a helper patch for simplifying futher work. It adds various configuration options to simplify dealting with different event loop implementations. Here it is: http://git.musicpd.org/cgit/dk/mpd.git/commit/?id=46bab7e4b921b79924643bacd08dcd3d1404ceb6 Also during testing I've found that AlsaMixerMonitor depends on epoll event loop (specifically on a AddCall method). This means it could not be compiled when GLib event loop is used. I didn't find immediately obvious way of fixing this, thus decided to leave it as is at the moment. -- Denis -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] New event loop implementation
27.11.2013 19:00, Max Kellermann пишет: That's not perfect but ok, because ALSA is Linux specific, and on Linux we always have epoll (there's no reason not to use it). OK. Do you have any comments on the patch itself? -- Denis -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] New event loop implementation
On 2013/11/27 14:18, Denis Krjuchkov de...@crazydev.net wrote: OK. Do you have any comments on the patch itself? Just read it merged. Looks excellent! -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] New event loop implementation
On 2013/11/19 13:12, Denis Krjuchkov de...@crazydev.net wrote: I'm trying to implement new event loop for MPD without GLib (or any other library). It's borrowed from existing epoll-based event loop. I only abstracted API differences behind general inteface (PollGroup class). Currently there are 3 backends: poll(), epoll() and Windows variant of select(). Code is poorly tested and has no comments at the moment, consider this a prototype. My few cents: - you reordered code in event/Loop.cxx, which makes reading the diff more difficult than necessary - the PollGroup/PollGroupImpl indirection adds unnecessary runtime overhead, without any advantage - why did you remove class EPollFD? Instead, PollGroupEPoll contains this abstraction code, plus the PollGroupImpl code. - why add overhead by storing the events in EventQueue? My implementation could work without this storage class. Your commit adds this overhead even to the epoll implementation. - why implement the SocketSet copy constructor? - you removed all the GLib code in that one commit, and added all new (untested) implementations; much of the commit deals with removing GLib specific code The last one is unfortunate, because it means we have to do the full switch in one big step. It would be better to have incremental patches which add one (optional) new implementation at a time; now we have to be sure all of them are mature at the same time. At the end, when we are portable across all platforms, we could remove the GLib implementation. -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] New event loop implementation
24.11.2013 21:06, Max Kellermann пишет: My few cents: Thanks for the comments! - you reordered code in event/Loop.cxx, which makes reading the diff more difficult than necessary That's my fault, probably I was addicted to Add/Modify/Remove trio in every class :-) - the PollGroup/PollGroupImpl indirection adds unnecessary runtime overhead, without any advantage This is done to hide implementation details and use single header for all implementations, but if you prefer to avoid that I could remove the indirection. - why did you remove class EPollFD? Instead, PollGroupEPoll contains this abstraction code, plus the PollGroupImpl code. This is done to encourage using universal PollGroup. - why add overhead by storing the events in EventQueue? My implementation could work without this storage class. Your commit adds this overhead even to the epoll implementation. This adds some overhead for the purpose of having single API for all backends. Another option is to use backend specific way to deliver events (e.g. make each backend provide its own variant of EventQueue that could be passed to syscall directly - or even intergrate whole event queue into the PollGroup). Since this is a prototype I've started with simplest approach of using std::deque, but I agree this could be improved. Alternative approach is to use some callback mechanism, but I find pull-style API more convenient to use. - why implement the SocketSet copy constructor? This is done to avoid copying whole fd_array, but instead copy only actually used elements. - you removed all the GLib code in that one commit, and added all new (untested) implementations; much of the commit deals with removing GLib specific code The last one is unfortunate, because it means we have to do the full switch in one big step. It would be better to have incremental patches which add one (optional) new implementation at a time; now we have to be sure all of them are mature at the same time. At the end, when we are portable across all platforms, we could remove the GLib implementation. I didn't expect this to be merged now. My plan was to polish the code until it is usable for development branch and then propose a merge. But probably we could make this more incremental and keep GLib code for a while. If so I think there should be a configure option to enable new event loop (or disable old). What do you think? I want to add one more backend that uses regular select(). In theory these 4 backends should cover most of the supported platforms. -- Denis -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
[Musicpd-dev-team] New event loop implementation
Hi all, I'm trying to implement new event loop for MPD without GLib (or any other library). It's borrowed from existing epoll-based event loop. I only abstracted API differences behind general inteface (PollGroup class). Currently there are 3 backends: poll(), epoll() and Windows variant of select(). Code is poorly tested and has no comments at the moment, consider this a prototype. Here is a full commit: http://git.musicpd.org/cgit/dk/mpd.git/commit/?id=4bcea6ea56fcb4d118d47fea5fa6106ab5883b1d How do you like this apporach? Are there any clear issues with this implementation? I'm currently concerned about (possible) thread-safety problems. What Loop methods are expected to be called from other threads? Any comments are appreciated. -- Denis -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
