From: Michael R. <mr...@us...> - 2004-01-18 19:10:30
|
Hi team, I have a problem. I think I have solved the rewire problems Miguel and I discussed in the thread "refined post plugin architecture". But unfortunately the solution got a bit complex, since the problem turned out to be more difficult than I thought. I attached three patches implementing my idea: kill-AO_PROP_PAUSE.patch Currently, some input plugins call a port function to set audio out into some pause mode. This is a bad thing. Decoders should be the only plugins in stream layer to call port functions. Furthermore, I do not understand, why the audio out needs to be informed separately about pause conditions, since it can derive that information by itself. Therefore I killed the AO_PROP_PAUSE entirely. Everybody please check, if I caused any races in audio out with that. I don't think so, but I did not understand some parts of the code (like ao_flush) to the last detail, so there is a bit of a danger here. ticket-system.patch This is my idea to solve the rewiring. I call it "ticket system" and it is like a read-write lock on steroids. There are five operations on this primitive: * acquire You need to have a ticket to access the resource it protects. You can also acquire a ticket irrevocably. See below. * release You no longer need the resource, so you give the ticket back. * renew This is an atomic combination of release and acquire. * revoke This revokes the ticket and waits, until all granted tickets have been given back before returning. Irrevocable tickets have to be given back by the holder explicitly. Revocable tickets will also be blocked on renew. When revoke returns, noone is accessing the resource the ticket protects, so you can use/modify it exclusively. * issue When you completed the exclusive operation, you call issue to give the tickets back to the threads waiting for a renew. Revocation and issuing can also be done atomic, so no other revoke can disturb you. The last two operations are only available inside the core engine. Some additional constraints have to be fulfilled for the system to work: * assure to release irrevocable tickets after a finite time * assure to renew revocable tickets after a finite time * assure to reissue tickets you revoke atomic after a finite time * pair calls properly * never revoke a ticket you hold * never acquire a ticket revocable you revoked before porting.patch This ports the engine and the post plugins to the ticket system. There is a global port ticket living in xine_t. While this could be more fine-grained, it is the easier and clearer solution for now. Rewiring is rare enough to not cause too much contention here. All port calls acquire and release this ticket properly. Post plugins get to know the ticket from the engine and renew it from time to time. All rewire operations revoke the port ticket. Switching the engine to pause mode also revokes the ticket, because that blocks the engine and therefore requires the consent of the ticket holders. Post plugins could even create blocks, where interruptions due to pausing or rewiring is not allowed by acquiring an irrevocable ticket. (Helper functions exist in post.h.) This can make some plugins easier (Miguel: deinterlace?), but it is not used yet. The OSD manager had to be changed a bit to retrieve the overlay manager regularly and not just once on initialization, because rewiring might connect you to a different manager. I would like to hear comments on the system and on how we should proceed with it. Michael -- die_if_kernel("Whee... Hello Mr. Penguin", current->tss.kregs); 2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c |