program contains an ad hoc, informally specified,
bug-ridden, slow implementation
of half of Common Lisp.
--Phil Greenspun's Tenth Law of Programming
I wasn't actually complaining about the lack of a mutex or anything else per se. I was just trying to get it perfectly straight in my mind exactly how we were getting away with things, specifically why no two threads ever attempted to service the same accept(). I, wrongly, assumed that select() would only awaken one thread for a pecific set of fd's triggering and that other threads in select() would wait for activity on the remaining fd's.
Hmm, thats not very clear.... which is exactly why I asked.
We are multiplexing our threads and there is usually a form of state machine involved but that is determined by the protocol in use. It usually takes the form of a command - response loop.
The thing that prompted all this was I noticed my server was handling new connections and not servicing existing connections (some little nerk trying to hack me) and another more complex situation that doesn't matter here.
Thanks to all for the information.
Wed Nov 11 2009 02:28:26 AM EST from dothebart @ Uncensoredhm, it was mstone I was talking about. _this_ definitely is one of my tripple-m's, IG.
Yes, mstone. used that before.
This amused me.. someone described the '-->' operator as the 'goes down to' operator:
Like x-> is equivilent to (*x)
It's not ->... it's -->.
it would be better written as
while ((x--) > 0)
just to eliminate the ambiguities.
hey, fleeb, i'd call that my first real good c-joke. Realy fucking cool!
Mine, too, dothebart! Cracked me up when I found it.
--> is the "state transition" operator, obviously.
while (x-- > 0)
would have been more understandable (or at least, not mistaken for an operator)
And kill the mystery?
Unfortunately I don't know of an easy way to get them all on the screen in a way that everyone here is guaranteed to be able to read. For that matter, a potential C compiler might have the same problem :)
I did something kind of fun today.
I created an input stream manipulator for a custom class.
std::string str( "+01:02:03:04" );
std::stringstream strm( str );
strm >> type( timecode::ePAL ) >> tc;
assert( tc.get_type() == timecode::ePAL );
std::stringstream strm1( str );
strm1 >> type( timecode::eDROP_FRAME_NTSC ) >> tc;
assert( tc.get_type() == timecode::eDROP_FRAME_NTSC );
I told Ford II a little about this project I've been working on, but if anyone else out there is into C++, and some of the funky things you can do with it, you might find this interesting, too.
I already mentioned elsewhere that I've been working on an object that allows you to work with timecode. I think I am nearly finished with this.
My timecode object, as it stands right now, can convert between a good number of different kinds of timecode, allows you to add and subtract between the various kinds of timecode, iterates frames or decrements frames, can express itself in wchar_t or char character types, and can express itself in terms of the boost 'ptime' object (think of this as a platform-independant expression of time). You can compare them against each other, such that you can figure out which bit of timecode happens before some other bit of timecode.
This timecode object can be streamed, either out or in. It won't throw an exception on a bad parse... it simply has a type of 'eUnknown'.
If you have some kind of time code that doesn't conform to any of the kinds of timecode I current understand, you can use this as a framework to create your own very easily, through a templated class. Under the covers, I use the same mechanism for all the kinds of timecode I know about (PAL, film, NTSC [drop frame or not], and this funky 3/5 pull-down thing that I hope I figured out right, plus the double-NTSC, double-drop-frame-NTSC rates for interleaved video). If you need to support a fixed frame rate that's unusual (e.g. 72 fps), it's as easy as templatizing my existing classes using '72' instead of, say, 30 or 25. Even if you come up with something that's downright ludicrous, I should most likely be able to handle it if you create a class to explain how to calculate the timecode, and drop it into the template.
The class that can convert between the known timecode types is a beauty, though. It uses something very much like the 'union' keyword, except that it works with complex types. So, the 'timecode' object can use any of my known typedeffed templated classes as its underlying type, yet still compare 'timecode' objects, even though they're completely different types. It can even perform calculations between the two different types... so you could conceptually subtract PAL timecode from NTSC drop-frame timecode and have it make some kind of sense. I would hope nobody would actually do this, but it's still pretty cool to be able to do.
At this point, I need to handle crossing the midnight boundary, and incrementing against days (or going negative). Otherwise, I think it's done.
Why YET ANOTHER LANGUAGE?
It sounds like a cross between java and C.
why why why.
If I've read it right, Google came up with a language named 'Go', but someone else has a language (that predates Google's Go) named 'Go!'.
Let the confusion continue.