From: Tim 'Tool-M. T. <ti...@to...> - 2001-03-29 07:44:46
|
Recently I've been rereading "Concurrent Programming in Java" by Doug Lea. One of the sections covers generic flow networks. Gstreamer being a multimedia flow network some of the terminology he used might be appropriate to gstreamer. I've added a Wiki page about it: <http://gstreamer.net/cgi-bin/wiki/moin.cgi/FlowNetwork> -- Tim Taylor ti...@to... |
From: Erik W. <om...@te...> - 2001-03-29 08:04:17
|
On Thu, 29 Mar 2001, Tim 'Tool-Man' Taylor wrote: > Recently I've been rereading "Concurrent Programming in Java" by Doug > Lea. One of the sections covers generic flow networks. Gstreamer being > a multimedia flow network some of the terminology he used might be > appropriate to gstreamer. I've added a Wiki page about it: > > <http://gstreamer.net/cgi-bin/wiki/moin.cgi/FlowNetwork> Cool! Though the ASCII diagrams are hard to follow in variable-width font. taaz, do you know the syntax for a <pre></pre> style markup? Erik Walthinsen <om...@te...> - System Administrator __ / \ GStreamer - The only way to stream! | | M E G A ***** http://gstreamer.net/ ***** _\ /_ |
From: Tim 'Tool-M. T. <ti...@to...> - 2001-03-29 08:14:38
|
Erik Walthinsen wrote: > On Thu, 29 Mar 2001, Tim 'Tool-Man' Taylor wrote: > > >> Recently I've been rereading "Concurrent Programming in Java" by Doug >> Lea. One of the sections covers generic flow networks. Gstreamer being >> a multimedia flow network some of the terminology he used might be >> appropriate to gstreamer. I've added a Wiki page about it: >> >> <http://gstreamer.net/cgi-bin/wiki/moin.cgi/FlowNetwork> > > > Cool! Though the ASCII diagrams are hard to follow in variable-width > font. taaz, do you know the syntax for a <pre></pre> style markup? Uhm...I already did that ;-) I used the Wiki syntax for a "source code" block, i.e.: {{{ ascii art here }}} Which it translates to: <pre class="code"> ascii art here </pre> Which is rendered monospace in NS4.x and mozilla under linux. Here's the relevant style from /wiki/default.css: pre.code { margin-top: 8pt; margin-bottom: 8pt; background-color: #E0E0E0; white-space:pre; border-style:none; border-width:thin; width:100%; } My guess is that it's probably flexing a CSS bug in your browser. You could try adding a 'font-family: monospace;' to the above and see if that fixes it. -- Tim Taylor ti...@to... |
From: David I. L. <dl...@vt...> - 2001-03-29 17:24:42
|
* Tim 'Tool-Man' Taylor <ti...@to...> [20010329 03:18]: > Erik Walthinsen wrote: > >> <http://gstreamer.net/cgi-bin/wiki/moin.cgi/FlowNetwork> > > > > Cool! Though the ASCII diagrams are hard to follow in variable-width > > font. taaz, do you know the syntax for a <pre></pre> style markup? > ... > Which is rendered monospace in NS4.x and mozilla under linux. Here's > the relevant style from /wiki/default.css: > > pre.code { > margin-top: 8pt; > margin-bottom: 8pt; > background-color: #E0E0E0; > white-space:pre; > border-style:none; > border-width:thin; > width:100%; > } > > My guess is that it's probably flexing a CSS bug in your browser. You > could try adding a 'font-family: monospace;' to the above and see if > that fixes it. > Blah.. I tried adding that. Didn't work for netscape here. Galeon works fine either way. If someone knows how to fix this speak up else it will just stay broken... hit the edit button if you need to see it monospace ;) -dave -- David I. Lehn <dl...@vt...> | http://www.lehn.org/~dlehn/ Computer Engineering Graduate @ Virginia Tech in sunny Blacksburg, VA |
From: Tim 'Tool-M. T. <ti...@to...> - 2001-03-30 02:26:46
|
David (and Erik), can you give me your browser version and OS? Be sure to specify which 'x' in Netscape 4.x if you're running it. I recall getting this exact same error in some version of NS4.x before when playing around with styles on PRE. If we can narrow down the offending browser I'll see if I can fix it. I'm running NS4.72 and it renders in monospace. Also, does the source code in this page render in monospace in your browser: <http://jsfc.sourceforge.net/> David I. Lehn wrote: > * Tim 'Tool-Man' Taylor <ti...@to...> [20010329 03:18]: > >> Erik Walthinsen wrote: >> >>>> <http://gstreamer.net/cgi-bin/wiki/moin.cgi/FlowNetwork> >>> >>> Cool! Though the ASCII diagrams are hard to follow in variable-width >>> font. taaz, do you know the syntax for a <pre></pre> style markup? >> > ... > >> Which is rendered monospace in NS4.x and mozilla under linux. Here's >> the relevant style from /wiki/default.css: >> >> pre.code { >> margin-top: 8pt; >> margin-bottom: 8pt; >> background-color: #E0E0E0; >> white-space:pre; >> border-style:none; >> border-width:thin; >> width:100%; >> } >> >> My guess is that it's probably flexing a CSS bug in your browser. You >> could try adding a 'font-family: monospace;' to the above and see if >> that fixes it. >> > > > Blah.. I tried adding that. Didn't work for netscape here. Galeon > works fine either way. If someone knows how to fix this speak up else > it will just stay broken... hit the edit button if you need to see it > monospace ;) > > -dave -- Tim Taylor ti...@to... |
From: David I. L. <dl...@vt...> - 2001-03-30 05:51:22
|
* Tim 'Tool-Man' Taylor <ti...@to...> [20010329 21:28]: > David (and Erik), can you give me your browser version and OS? Be sure > to specify which 'x' in Netscape 4.x if you're running it. > > I recall getting this exact same error in some version of NS4.x before > when playing around with styles on PRE. If we can narrow down the > offending browser I'll see if I can fix it. I'm running NS4.72 and it > renders in monospace. > > Also, does the source code in this page render in monospace in your browser: > > <http://jsfc.sourceforge.net/> > netscape 4.76, latest debian unstable packages for x, fonts, ns, etc. the jsfc source block looks fine. and yes, i'm too lazy to figure it out based on this info ;) -dave -- David I. Lehn <dl...@vt...> | http://www.lehn.org/~dlehn/ Computer Engineering Graduate @ Virginia Tech in sunny Blacksburg, VA |
From: Tim 'Tool-M. T. <ti...@to...> - 2001-03-30 23:31:18
|
One quick workaround would be to change wiki-support/default.css to have: @media all { /* XXX: NS4.x ignores @media */ pre.code { margin-top: 8pt; } /* XXX: dummy selector for IE4 */ pre.code { margin-top: 8pt; margin-bottom: 8pt; background-color: #E0E0E0; white-space: pre; border-style: none; border-width: thin; width: 100%; } } This will cause NS4.x to do the default rendering of PRE while less broken browsers render it with the appropriate styling. Otherwise, here's the CSS I use on the JSFC sourcecode blocks: pre.codeblock, pre.diagram { padding: .75em; margin: 1em 2em; font-family: "Courier New", Courier, Monaco, monospace; color: black; background: aqua; } pre.codeblock, pre.diagram { /* XXX: NS 4 */ border: none; font-size: 1em; /* XXX: Linux NS 4 doesn't seem to obey this */ white-space: pre; } You reported that it renders monospace in NS4.76 on Debian. Erik replied privately that on two theoretically identical machines (RH7.0, NS4.76) one rendered it in monospace, the other in variable width. You could try the following if you're willing to settle for 2 out of 3 :) : pre.code { margin-top: 8pt; margin-bottom: 8pt; background: #E0E0E0; font-family: "Courier New", Courier, Monaco, monospace; } pre.code { /* XXX: NS4.x */ border: none; white-space: pre; } Which is my untested merger of the Wiki styles with the JSFC styles, so who knows what new CSS bugs will be flexed by the differences :/ Tim David I. Lehn wrote: > * Tim 'Tool-Man' Taylor <ti...@to...> [20010329 21:28]: > >> David (and Erik), can you give me your browser version and OS? Be sure >> to specify which 'x' in Netscape 4.x if you're running it. >> >> I recall getting this exact same error in some version of NS4.x before >> when playing around with styles on PRE. If we can narrow down the >> offending browser I'll see if I can fix it. I'm running NS4.72 and it >> renders in monospace. >> >> Also, does the source code in this page render in monospace in your browser: >> >> <http://jsfc.sourceforge.net/> >> > > netscape 4.76, latest debian unstable packages for x, fonts, ns, etc. > > the jsfc source block looks fine. and yes, i'm too lazy to figure it > out based on this info ;) > > -dave -- Tim Taylor ti...@to... |
From: David I. L. <dl...@vt...> - 2001-04-14 18:43:38
|
* Tim 'Tool-Man' Taylor <ti...@to...> [20010330 18:37]: > One quick workaround would be to change wiki-support/default.css to have: > > @media all { /* XXX: NS4.x ignores @media */ > pre.code { margin-top: 8pt; } /* XXX: dummy selector for IE4 */ > pre.code { > margin-top: 8pt; > margin-bottom: 8pt; > background-color: #E0E0E0; > white-space: pre; > border-style: none; > border-width: thin; > width: 100%; > } > } > > This will cause NS4.x to do the default rendering of PRE while less > broken browsers render it with the appropriate styling. > Well... i did a different fix. i commented out border-width. that makes it look kinda dumb cause background isn't stretched to the right. but it looks ok in mozilla and its monospace in ns 4.7 it seems. good enough for me. -dave -- David I. Lehn <dl...@vt...> | http://www.lehn.org/~dlehn/ Computer Engineering Graduate @ Virginia Tech in sunny Blacksburg, VA |
From: Matt H. <ma...@ri...> - 2001-03-29 17:08:18
Attachments:
Scheduling03-29-01.txt
|
erik, brent and i spent some time talking about plans for scheduling re-work of GStreamer. following are the notes which i'll also check into docs/random. take a look and comment / correct. matt. ps - erik and i hope to get this done within a couple of weeks. ----- |
From: Tim 'Tool-M. T. <ti...@to...> - 2001-03-30 02:56:41
|
I took the liberty of putting Matt's notes into Wiki: <http://gstreamer.sourceforge.net/cgi-bin/wiki/moin.cgi/SchedulingAndSynchronization> And linked to it (and the FlowNetwork) from GstDocumentation: <http://gstreamer.sourceforge.net/cgi-bin/wiki/moin.cgi/GstDocumentation> BTW, does anyone mind doing some mod_rewrite magic on these Wiki URLs? Being able to shorten the above URL to something like... http://gstreamer.sourceforge.net/Wiki/GstDocumentation ...would really be grand. Besides, having "cgi-bin" in a URL is so last millenium ;) Tim Matt Howell wrote: > erik, brent and i spent some time talking about plans for scheduling re-work > of GStreamer. following are the notes which i'll also check into docs/random. > > take a look and comment / correct. > > matt. > > ps - erik and i hope to get this done within a couple of weeks. > > ----- > > > > ------------------------------------------------------------------------ > > ----------------------------------------------------------- > - GStreamer Scheduling / Synchronization (incsched) Notes - > ----------------------------------------------------------- > > These notes describe deadlock scenarios and proposed solutions for > GStreamer. This will be implemented in the INCSCHED1 branch. > > I. Miscelaneous proposals > II. Deadlock scenarios and propsed solutions > III. State transition approach and responsibility > > MattH. > > -------------------------------- > - I. Miscalenous proposals - > -------------------------------- > > 1. Change the names of GstThread and GstQueue to GstPtThread and GstPtQueue > for pthread versions of Thread and Queue. > > 2. Change GstPtQueue to check its pads' peers' managers and make sure > they are different. If not, fail and generate error message. (This > ensures a GstPtQueue straddles a pthread boundary.) > > 3. Change state transitions to NULL <-> READY <-> PAUSED <-> PLAYING. > > > --------------------------------------------------- > - II. Deadlock Scenarios and Proposed Solutions - > - (in the order they will be implemented) - > --------------------------------------------------- > > 1. A downstream element "waits" for a buffer from its upstream element, > a state change happens and "pauses" the upstream element -- the > downstream element is blocked and cannot execute its change_state. > > Note that this can only happen within a single GstPtQueue! Either a > downstream element calls Pull, finds no buffer, and does a > wait_cond(new buffer) or an upstream element calls Push, finds no > room, and does a wait_cond(new room). Thus, GstPtQueue contains all > the cond_wait / signal code. > > => The managing container (thread, pipeline) "wakes" up any sleep > conditions of its "bottom half". (In the scenario described, it > wakes the blocked downstream element's call to Pull.) The GstPtQueue > cond_wait section determines that it woke up due to a pending state > change and does a cothread_switch(0) to return to the main loop, > which then executes the state transition. > > Note that a managing container will have only one sleep condition > in its "bottom half." > > > 2. Element "blocked" on getting I/O and cannot execute its change_state. > > => We will provide an I/O library for the elements to use that does > not actually block. (A retry-loop with timeout or select() on > 2 -- or more -- file descriptors: one the one you want I/O from, > the other one that GStreamer uses to "wake" everyone up.) The > I/O library determines that it was woken due to a pending state > change and does a cothread_switch(0) to return to the main loop, > which then executes the state transition. > > Note that a managing container will have only one elements in > the middle of doing blocking I/O. > > > 3. Element using a library (code out of its control) which blocks for > some reason (e.g., using real blocking I/O) so main loop never gets > run to execute change_state. > > => Build in some timeout in the manging container (the "top half") > when waiting for bottom half to respond to pending state. If > managing container times out, kill the element's thread with a > signal (or series of signals -- escalating priority). This > requires that the element (the "bottom half") have matching > signal handler(s) that execute(s) the state-transition. > > > -------------------------------------------------------- > - III. State-transition Approach and Responsibility - > -------------------------------------------------------- > > A. The "top half" context of the managing container. (This is likely the > context of the application.) > > Call change_state on the managing container (GstPipeline, GstPtThread). > If its "bottom half" (main_loop) is asleep, signal the condition to > wake it up. Then do a cond_wait for the "bottom half" to execute the > state transition and return (once the state has been changed). > > > B. The main_loop (the "bottom half") of the managing container. > > Needs to check for pending state transition after every switch back from > one of its elements. If a pending state is found, it calls change_state > on each of its elements, signals the "top half" that the state has been > changed, then continues executing the plan (if Playing) or puts itself > to sleep (Paused, Ready). > > > C. Element. > > Implement a change_state function to make transition for that element. > The elements' change_state is what actually changes the state variable > and notifies the scheduler that the state was changed. This function > may also do things like close or open resources. > > NOTE: when an element goes through certain state transitions (e.g., from > Paused to Ready) its state (stack) will be wiped out. If it wants to > preserve any state or data, it needs to store the information in a safe > place. > > > D. Cothread Scheduler. > > Gets notified of state transition by elements' change_state functions > then (re)set the plan accordingly. Assuming > NULL <-> READY <-> PAUSED <-> PLAYING, some would be > > + Paused -> Playing: jump back where you were in the Plan and continue > its execution > > + Ready -> Paused: reset the cothread pointers foreach cothread in the > Plan (don't run) > Scheduling03-29-01.txt > > Content-Type: > > text/plain > Content-Encoding: > > 7bit -- Tim Taylor ti...@to... |
From: Erik W. <om...@te...> - 2001-03-30 02:59:17
|
On Thu, 29 Mar 2001, Tim 'Tool-Man' Taylor wrote: > I took the liberty of putting Matt's notes into Wiki: > > <http://gstreamer.sourceforge.net/cgi-bin/wiki/moin.cgi/SchedulingAndSynchronization> > > And linked to it (and the FlowNetwork) from GstDocumentation: > > <http://gstreamer.sourceforge.net/cgi-bin/wiki/moin.cgi/GstDocumentation> Cool, thanx! > BTW, does anyone mind doing some mod_rewrite magic on these Wiki URLs? > Being able to shorten the above URL to something like... > http://gstreamer.sourceforge.net/Wiki/GstDocumentation If you can get the sourceforge people to do it, sure! > ...would really be grand. Besides, having "cgi-bin" in a URL is so last > millenium ;) That's one way to put it <g> Erik Walthinsen <om...@te...> - System Administrator __ / \ GStreamer - The only way to stream! | | M E G A ***** http://gstreamer.net/ ***** _\ /_ |
From: Tim 'Tool-M. T. <ti...@to...> - 2001-03-30 03:36:54
|
Erik Walthinsen wrote: > On Thu, 29 Mar 2001, Tim 'Tool-Man' Taylor wrote: >> BTW, does anyone mind doing some mod_rewrite magic on these Wiki URLs? >> Being able to shorten the above URL to something like... >> http://gstreamer.sourceforge.net/Wiki/GstDocumentation > > If you can get the sourceforge people to do it, sure! You can turn it on in the .htaccess in your root htdocs. Here, I finally did the work instead of being lazy and asking someone else to figure it out 8-) . If you put this in .htaccess (which I assume is located somewhere like htdocs/.htaccess) then it /should/ work: # # URL rewriting # RewriteEngine on # friendlier Wiki URLs RewriteRule Wiki/(.*)$ /cgi-bin/wiki/moin.cgi/$1 [L] I used captial 'Wiki' because there already exists a http://gstreamer.sourceforge.net/wiki/ with miscellaneous files (images, stylesheets, etc.). Now, I don't know if the MoinMoin constructs relative or absolute URLs for it's internal links. If it uses absolute URLs then it sorta defeats the point of the doing the URL rewriting. More URL rewriting could be used as a workaround, but it would be kludgey. Hopefully MoinMoin uses relative URLs. If this /does/ work, someone might want to change the link to Wiki in the main site navigation. The rest of this message is just an FYI on rewrite rules placed in .htaccess and can be ignored. The big gotcha to watch out for is that unlike rewrite rules placed in the configuration files (like in a VirtualHost section), the regex matching expression is relative to the directory .htaccess is in. This is explained easier with an example: Say we want to redirect http://gstreamer.sourceforge.net/foo to http://gstreamer.sourceforge.net/bar. In httpd.conf we'd use: <VirtualHost gstreamer> ... RewriteRule ^/foo$ /bar </VirtualHost> But in [public html root]/.htaccess the leading '/' to the URL is stripped, so we need to omit it in the matching part of the regex, i.e.: ... RewriteRule ^foo$ /bar -- Tim Taylor ti...@to... |
From: David I. L. <dl...@vt...> - 2001-03-30 05:58:49
|
* Tim 'Tool-Man' Taylor <ti...@to...> [20010329 22:41]: > Erik Walthinsen wrote: > > > On Thu, 29 Mar 2001, Tim 'Tool-Man' Taylor wrote: > >> BTW, does anyone mind doing some mod_rewrite magic on these Wiki URLs? > >> Being able to shorten the above URL to something like... > >> http://gstreamer.sourceforge.net/Wiki/GstDocumentation > > > > If you can get the sourceforge people to do it, sure! > ... > RewriteRule Wiki/(.*)$ /cgi-bin/wiki/moin.cgi/$1 [L] > ok, did this. well, sorta: http://gstreamer.net/wiki http://gstreamer.net/wiki/ http://gstreamer.net/wiki/GstDocumentation These all work... old wiki dir moved to wiki-support/. Cap Wiki not my style. ;) But the URLs in the pages are still to cgi-bin. This is MoinMoin 0.8. It's probably fixable, I'm just not sure how. ;) Probably MoinMoin grabbing the rewritten url vs the requested url? -dave -- David I. Lehn <dl...@vt...> | http://www.lehn.org/~dlehn/ Computer Engineering Graduate @ Virginia Tech in sunny Blacksburg, VA |
From: Tim 'Tool-M. T. <ti...@to...> - 2001-03-30 23:13:07
|
David I. Lehn wrote: > ok, did this. well, sorta: > > http://gstreamer.net/wiki > http://gstreamer.net/wiki/ > http://gstreamer.net/wiki/GstDocumentation > > These all work... old wiki dir moved to wiki-support/. Cap Wiki not my > style. ;) Great! I prefer lowercase URLs as well. > But the URLs in the pages are still to cgi-bin. This is MoinMoin 0.8. > It's probably fixable, I'm just not sure how. ;) Probably MoinMoin > grabbing the rewritten url vs the requested url? AFAIK, all Wiki URLs are at the same level, so there's no reason to include an absolute path. Once on a Wiki page, a URL to just the wiki name should suffice, i.e.: In <http://gstreamer.net/wiki/GstDocumentation>: ... <hr> <a href="SchedulingAndSynchronization">SchedulingAndSynchronization</a> covers Gstreamer incremental scheduling and the concurrent programming issues surrounding it. <p><hr> ... Using the MoinMoin CVSWeb I've isolated the relevant code in MoinMoin/wikiutil.py: 216: return ('<a%s href="%s/%s">%s</a>' 217: % (classattr, util.getScriptname(), params, text)) Change that to: 216: return ('<a%s href="%s">%s</a>' 217: % (classattr, params, text)) Apologies for not sending a patch. -- Tim Taylor ti...@to... |
From: David I. L. <dl...@vt...> - 2001-04-14 18:41:46
|
* Tim 'Tool-Man' Taylor <ti...@to...> [20010330 18:16]: > Using the MoinMoin CVSWeb I've isolated the relevant code in > MoinMoin/wikiutil.py: > > 216: return ('<a%s href="%s/%s">%s</a>' > 217: % (classattr, util.getScriptname(), params, text)) > > Change that to: > > 216: return ('<a%s href="%s">%s</a>' > 217: % (classattr, params, text)) > ok, that worked. had to take out a bunch of other scriptname references for header and footer of the page. don't know how to fix the title lookup thing easily so i'll just leave that. this stuff break the old cgi-bin wiki thing btw. -dave -- David I. Lehn <dl...@vt...> | http://www.lehn.org/~dlehn/ Computer Engineering Graduate @ Virginia Tech in sunny Blacksburg, VA |
From: Tim 'Tool-M. T. <ti...@to...> - 2001-03-31 00:22:08
|
Matt Howell wrote: [snip] > --------------------------------------------------- > - II. Deadlock Scenarios and Proposed Solutions - > - (in the order they will be implemented) - > --------------------------------------------------- > > 1. A downstream element "waits" for a buffer from its upstream element, > a state change happens and "pauses" the upstream element -- the > downstream element is blocked and cannot execute its change_state. > [snip] > 2. Element "blocked" on getting I/O and cannot execute its change_state. [snip] > 3. Element using a library (code out of its control) which blocks for > some reason (e.g., using real blocking I/O) so main loop never gets > run to execute change_state. Unless I'm missing something, none of these scenarios describe Deadlock. They describe liveness problems. Deadlock is when two threads lock on eachother, each awaiting a condition that only the other thread can fulfill. -- Tim Taylor ti...@to... |
From: Matt H. <ma...@ri...> - 2001-03-31 21:52:15
|
you're correct, tim -- i used the term loosely. a more precise title would be "State-change Race Conditions and Proposed Solutions" Tim 'Tool-Man' Taylor wrote: > Matt Howell wrote: > > [snip] > > > --------------------------------------------------- > > - II. Deadlock Scenarios and Proposed Solutions - > > - (in the order they will be implemented) - > > --------------------------------------------------- > > > > 1. A downstream element "waits" for a buffer from its upstream element, > > a state change happens and "pauses" the upstream element -- the > > downstream element is blocked and cannot execute its change_state. > > > [snip] > > > 2. Element "blocked" on getting I/O and cannot execute its change_state. > [snip] > > > 3. Element using a library (code out of its control) which blocks for > > some reason (e.g., using real blocking I/O) so main loop never gets > > run to execute change_state. > > Unless I'm missing something, none of these scenarios describe Deadlock. > They describe liveness problems. Deadlock is when two threads lock on > eachother, each awaiting a condition that only the other thread can fulfill. > > -- > Tim Taylor > ti...@to... > > _______________________________________________ > gstreamer-devel mailing list > gst...@li... > http://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
From: Tim 'Tool-M. T. <ti...@to...> - 2001-04-01 17:57:59
|
Matt Howell wrote: > you're correct, tim -- i used the term loosely. a more precise title would be > "State-change Race Conditions and Proposed Solutions" Now, you're probably going to think I'm trying to pick a fight :) ... Unless I've misunderstood one of the scenarios (a distinct possibility) a more accurate heading would be: "Liveness Problems and Proposed Solutions". I don't see how they are race conditions, either. It's tempting to think of deadlock as a type of race condition, but typically the term "race condition" is reserved for describing code that relies on scheduling to keep other threads from accessing objects in intermediate (i.e. inconsistent) states. I don't mean to be pedantic. However, my C-fu is minimal and my concurrent C programming skills are non-existent, so I can't divine understanding by perusing the code...at least not easily. The higher level documentation and notes are how I grok gstreamer right now. I'm /not/ saying these scenarios don't have deadlock or race conditions. I'm saying "I don't see them". That may mean they aren't there. More likely it means means I lack the understanding of gstreamer internals to "see" them based on your notes. This is probably fine. Your notes were intended for internal developers, not for gstreamer groupies like me :) -- Tim Taylor ti...@to... |
From: Matt H. <ma...@ri...> - 2001-04-01 19:39:03
|
i should have spent more time on my initial response. you're correct: none of these are race conditions. basically i don't like the term "liveness" -- but that's not important. "Liveness Problems..." is fine and correctly describes all the scenarios. fyi, i consider case 1 deadlock because: + B waiting for A to wake it up (with data) + A waiting for B to wake it up (that B executed change state) => (taking some liberty) the deadlock condition is "i'm waiting for you to wake me up" this is not 100% correct because the real conditions are different -- "data" vs "changed state" -- but i've always considered this deadlock. matt. -- Tim 'Tool-Man' Taylor wrote: > Now, you're probably going to think I'm trying to pick a fight :) ... > > Unless I've misunderstood one of the scenarios (a distinct possibility) > a more accurate heading would be: "Liveness Problems and Proposed > Solutions". > > I don't see how they are race conditions, either. It's tempting to > think of deadlock as a type of race condition, but typically the term > "race condition" is reserved for describing code that relies on > scheduling to keep other threads from accessing objects in intermediate > (i.e. inconsistent) states. > > I don't mean to be pedantic. However, my C-fu is minimal and my > concurrent C programming skills are non-existent, so I can't divine > understanding by perusing the code...at least not easily. The higher > level documentation and notes are how I grok gstreamer right now. > > I'm /not/ saying these scenarios don't have deadlock or race conditions. > I'm saying "I don't see them". That may mean they aren't there. More > likely it means means I lack the understanding of gstreamer internals to > "see" them based on your notes. This is probably fine. Your notes were > intended for internal developers, not for gstreamer groupies like me :) > > -- > Tim Taylor > ti...@to... > > _______________________________________________ > gstreamer-devel mailing list > gst...@li... > http://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
From: Tim 'Tool-M. T. <ti...@to...> - 2001-04-02 21:24:40
|
I see the light :) Case 1 is deadlock, no liberty taking necessary. Matt Howell wrote: > i should have spent more time on my initial response. you're correct: > none of these are race conditions. basically i don't like the term > "liveness" -- but that's not important. "Liveness Problems..." is fine > and correctly describes all the scenarios. > > fyi, i consider case 1 deadlock because: > + B waiting for A to wake it up (with data) > + A waiting for B to wake it up (that B executed change state) > => (taking some liberty) the deadlock condition is > "i'm waiting for you to wake me up" > this is not 100% correct because the real conditions are different -- > "data" vs "changed state" -- but i've always considered this deadlock. > > matt. > -- > Tim 'Tool-Man' Taylor wrote: > > >> Now, you're probably going to think I'm trying to pick a fight :) ... >> >> Unless I've misunderstood one of the scenarios (a distinct possibility) >> a more accurate heading would be: "Liveness Problems and Proposed >> Solutions". >> >> I don't see how they are race conditions, either. It's tempting to >> think of deadlock as a type of race condition, but typically the term >> "race condition" is reserved for describing code that relies on >> scheduling to keep other threads from accessing objects in intermediate >> (i.e. inconsistent) states. >> >> I don't mean to be pedantic. However, my C-fu is minimal and my >> concurrent C programming skills are non-existent, so I can't divine >> understanding by perusing the code...at least not easily. The higher >> level documentation and notes are how I grok gstreamer right now. >> >> I'm /not/ saying these scenarios don't have deadlock or race conditions. >> I'm saying "I don't see them". That may mean they aren't there. More >> likely it means means I lack the understanding of gstreamer internals to >> "see" them based on your notes. This is probably fine. Your notes were >> intended for internal developers, not for gstreamer groupies like me :) >> >> -- >> Tim Taylor >> ti...@to... >> >> _______________________________________________ >> gstreamer-devel mailing list >> gst...@li... >> http://lists.sourceforge.net/lists/listinfo/gstreamer-devel > > > > _______________________________________________ > gstreamer-devel mailing list > gst...@li... > http://lists.sourceforge.net/lists/listinfo/gstreamer-devel -- Tim Taylor ti...@to... |
From: orion h. <oh...@bt...> - 2001-04-01 20:02:28
|
Matt Howell wrote: > > erik, brent and i spent some time talking about plans for scheduling re-work > of GStreamer. following are the notes which i'll also check into docs/random. > > take a look and comment / correct. > > matt. > > ps - erik and i hope to get this done within a couple of weeks. > > ----- > > ------------------------------------------------------------------------ > ----------------------------------------------------------- > - GStreamer Scheduling / Synchronization (incsched) Notes - > ----------------------------------------------------------- > > These notes describe deadlock scenarios and proposed solutions for > GStreamer. This will be implemented in the INCSCHED1 branch. > > I. Miscelaneous proposals > II. Deadlock scenarios and propsed solutions > III. State transition approach and responsibility > > MattH. > > -------------------------------- > - I. Miscalenous proposals - > -------------------------------- > > 1. Change the names of GstThread and GstQueue to GstPtThread and GstPtQueue > for pthread versions of Thread and Queue. > > 2. Change GstPtQueue to check its pads' peers' managers and make sure > they are different. If not, fail and generate error message. (This > ensures a GstPtQueue straddles a pthread boundary.) > > 3. Change state transitions to NULL <-> READY <-> PAUSED <-> PLAYING. > > --------------------------------------------------- > - II. Deadlock Scenarios and Proposed Solutions - > - (in the order they will be implemented) - > --------------------------------------------------- > > 1. A downstream element "waits" for a buffer from its upstream element, > a state change happens and "pauses" the upstream element -- the > downstream element is blocked and cannot execute its change_state. > > Note that this can only happen within a single GstPtQueue! Either a > downstream element calls Pull, finds no buffer, and does a > wait_cond(new buffer) or an upstream element calls Push, finds no > room, and does a wait_cond(new room). Thus, GstPtQueue contains all > the cond_wait / signal code. > > => The managing container (thread, pipeline) "wakes" up any sleep > conditions of its "bottom half". (In the scenario described, it > wakes the blocked downstream element's call to Pull.) The GstPtQueue > cond_wait section determines that it woke up due to a pending state > change and does a cothread_switch(0) to return to the main loop, > which then executes the state transition. > > Note that a managing container will have only one sleep condition > in its "bottom half." > > 2. Element "blocked" on getting I/O and cannot execute its change_state. > > => We will provide an I/O library for the elements to use that does > not actually block. (A retry-loop with timeout or select() on > 2 -- or more -- file descriptors: one the one you want I/O from, > the other one that GStreamer uses to "wake" everyone up.) The > I/O library determines that it was woken due to a pending state > change and does a cothread_switch(0) to return to the main loop, > which then executes the state transition. > > Note that a managing container will have only one elements in > the middle of doing blocking I/O. > > 3. Element using a library (code out of its control) which blocks for > some reason (e.g., using real blocking I/O) so main loop never gets > run to execute change_state. > > => Build in some timeout in the manging container (the "top half") > when waiting for bottom half to respond to pending state. If > managing container times out, kill the element's thread with a > signal (or series of signals -- escalating priority). This > requires that the element (the "bottom half") have matching > signal handler(s) that execute(s) the state-transition. Disclaimer: *** I'm not privy to the previous discussions on this, nor am I fully upto speed on gstreamer; just started hacking some plugins this week. *** Another way of dealing with blocking I/O is to put the scheduler of a given bin into a separate thread. All of the elements run their chaining functions within that thread. If a source or sink blocks the elements in the bin block with it, but there's no spinning and no i/o changes on imported modules. A change of state to the elements of the bin just requires cancelling the bin's scheduling thread and invoking the change_state functions of the individual elements. Did this get ruled out already? Kind Regards - Orion |
From: David I. L. <dl...@vt...> - 2001-03-30 07:50:42
|
* Matt Howell <ma...@ri...> [20010329 12:16]: > > 1. Change the names of GstThread and GstQueue to GstPtThread and GstPtQueue > for pthread versions of Thread and Queue. > Why? Is it going to be possible to replace all pthread code with newer glib threading api? Seems that would be the best solution to solve cross platform issues. Now's probably the time to tell the glib people if they left something out of the api that gstreamer needs. -dave -- David I. Lehn <dl...@vt...> | http://www.lehn.org/~dlehn/ Computer Engineering Graduate @ Virginia Tech in sunny Blacksburg, VA |
From: Laurent L. <lau...@cy...> - 2001-03-30 08:04:00
|
is there a solution to detect the integrity of a mp3 file ? because when I want to play a mp3 that is not complete or corrupted, the gstmediaplay crash. what can I do to avoid this crash ? thanx. Laurent Lacaze lau...@cy... CYBERDECK SA Lyon, France |