[ECOS] problem with multi_lo_select.c

sandeep shimple0@yahoo.com
Mon Nov 29 13:31:00 GMT 2004

just as a note, the same task that was accomplished using liscnt and mutex m0,
could be achieved if ecos had a support of counting semaphores that went like
(cnt_sem.cxx and cnt_sem2.cxx don't provide this) --

initialise the counting semaphore with -N 
the waiting-thread waits for value >=0
each of N waited-for-completion-task thread posts and increments the count by 1

this kind of counting semaphore implementation could be useful, actually that's
what was my impression of counting semaphore implementation when i first found
the file cnt_sem.cxx (not finding it there had looked at cnt_sem2.cxx in the

> are happy with your current tests and then for you to submit a single
> patch against the current CVS. Depending on the size and scope of the
> changes we may need an assignment from you to commit it.
IMO, it would be better to keep fixing the things in cvs, as we come to know.
this has the advantage that other developers who are non-openly working on SMP
eCos, can verify them. This way more of them could be encouraged to talk about
SMP issues and submit patches and i hope in less than an year we have eCos 2.1
release which is much more solid/stable SMP than 2.0 .

having small-small fixes/patches getting into cvs will also save the hassles of
copyright, which often delays the things, at times for toooo long to render
things useless.

since i have hardly seen eCos and not likely to see it completely, like any
average developer, only the components/code-paths/options as per needs. having
a patch against entire cvs, and waiting for it, doesn't make much sense and it
can't be an honest patch against entire cvs.

I can send minor patches for some of the issues that i have discussed so far,
and more as and when i keep coming across.

It makes sense to go into copyright assignment business if I contribute a fresh
test or change the organisation of test significantly in one go.

if you wait for one large single patch, it may be too delayed and matters might
be complicated then. current management has people who support opensource
contribution, tomorrow it may not be the case, one might not be allowed to
contribute patches/ talk about SMP issues on list, as that might come in the
way of business. this organisation may not have me or i might not be working on
eCos. but no matter what, eCos should/will continue to grow in market.

if we take hints from past, it is almost an year that racoon contribution lies
unfinished. priorities/focus of every organisation change with time/workload.


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

More information about the Ecos-discuss mailing list