but then we would (again) need to track the clone syscalls
in order to increment the reference counter.
Both implementations require to add an adeos event, the one I chose, if
it works, avoid reference counting.
--
Gilles C
Dmitry Adamushko wrote:
> On 08/05/06, Gilles Chanteperdrix <[EMAIL PROTECTED]> wrote:
> > Jan Kiszka wrote:
> > > Likely I did not yet get the full picture: What prevents using another
> > > adeos per-task key for this?
> >
> > We would need a
Gilles Chanteperdrix wrote:
> These patches are not ready for inclusion, they are not tested
> yet.
The attached versions are tested. I still wonder if handling this in
shadow.c is the right solution, or if there should be an xnppd_set call
that could be called from within the skins
Gilles Chanteperdrix wrote:
> Gilles Chanteperdrix wrote:
> > These patches are not ready for inclusion, they are not tested
> > yet.
>
> The attached versions are tested.
...but the kernel patch is buggy. Here are t
Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
> > Gilles Chanteperdrix wrote:
> > > These patches are not ready for inclusion, they are not tested
> > > yet.
> >
> > The attached versions are tested. I still wonder if handling this in
> >
t does not work on SMP because the kgdb patch uses
smp_processor_id(), which does not work on SMP over Xenomai domain.
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
> > Philippe Gerum wrote:
> > > Gilles Chanteperdrix wrote:
> > > > Gilles Chanteperdrix wrote:
> > > > > These patches are not ready for inclusion, they are not tested
> > > &g
Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
> > Jan Kiszka wrote:
> > > BTW, this reminds me the ask for a merging plan of the kgdb support for
> > > ipipe - this bug was tracked down via kgdb...
> >
> > There are some issues with the kgdb patch:
e overall performance
> noticeably even if there is now kgdb or ltt? Or should we make this
> "ipipe-safe" smp_processor_id() optional for such users?
ipipe_current_domain uses ipipe_processor_id, so that replacing
smp_processor_id with :
if (ipip
re in the problematic situation
? Can we do the house keeping in the callback registered with
xnsynch_register_cleanup, or are you talking of a different situation ?
--
Gilles Chanteperdrix.
___
Xenomai
without calling xnsynch_sleep_on, so
probably need fixing.
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
/lib/tls/libpthread.so.0
> #5 0x0ffd08e8 in start_thread () from /lib/tls/libpthread.so.0
> Previous frame inner to this frame (corrupt stack?)
I observed such an error when the stack size is to small, I guess
vfprintf uses alloca.
--
Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
> > The attached version of the patch do that.
>
> Fine with me, please merge as you see fit. Details follow:
>
> > +++ include/nucleus/ppd.h 2006-05-10 14:27:11.0 +0200
> > @@ -0,0 +1,26 @@
&g
ething like
--mode=exec gdb
> Is it normal that a "make check" only works, if one builds the simulator
> inside the source code?
Last time I checked it worked when built out-of-tree, but you must build
the simulator in the sim su
Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
> > Philippe Gerum wrote:
> > > prio(task1) > prio(task2)
> > >
> > > 1. task1 grabs a resource
> > > 2. task1 sleeps for some time
> > > 3. task2 blocks requesting the resou
Gilles Chanteperdrix wrote:
> Niklaus Giger wrote:
> > Hi
> >
> > Running the sim testsuite vxworks (revision 1078) (using the attached
> script)
> > I get the following a few failures and memory corruption:
> >
> > trestart.c:
Niklaus Giger wrote:
> Do you have any ideas? Thanks in advance.
No idea, the x86 version does not seem to have the same problem, but
valgrind give many errors.
--
Gilles Chanteperdrix.
___
Xenomai-c
Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
>
> >
> > > Is it normal that a "make check" only works, if one builds the
> > simulator
> > > inside the source code?
> >
> > Last time I checked it worked when built out
m
Applied, thanks.
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
ode; so, when the system timer
is configured in periodic mode, the test should pass.
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Jan Kiszka wrote:
> Hi,
>
> this patch fixes a gcc-4.1 error in the nmi watchdog code on i386.
Applied, thanks.
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.
Jan Kiszka wrote:
> Hi Gilles,
>
> obviously, the userspace part of pthread_set_mode_np was forgotten on
> the last refactoring. This fixes it.
Applied, thanks.
--
Gilles Chanteperdrix.
___
Niklaus Giger wrote:
> Am Montag, 22. Mai 2006 13:38 schrieb Gilles Chanteperdrix:
> > Niklaus Giger wrote:
> > > Am Samstag, 20. Mai 2006 23:07 schrieb Philippe Gerum:
> > > > Here is the second release candidate for the v2.2 branch. Short log
> > &g
Niklaus Giger wrote:
> Do you have any clue? (Doubling the stack in vm/thread.cc didn't help.)
Automatic re-building does not work for the simulator. So, in case of
segmentation fault, try:
make clean all check
--
Gilles Chant
ad_t argument that is not yet initialized. But
if the not yet initialized pthread_t value is an invalid address, it
may cause a segmentation fault. The best thing to do is to remove this
test.
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
sue, isn't it? Likely due to some picky gcc
> switch during the simulator build.
It depends on what is defined at line 69 of pthreadtypes.h...
--
Gilles Chanteperdrix.
Index: sim/skins/posix/posix_overrides.h
Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
> > Jan Kiszka wrote:
> > > Hi,
> > >
> > > I just tried to get the simulator from trunk built but failed here:
> > >
> > > In file included from
> > ../../../../xenomai/si
ication to be done at Xenomai level.
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
is set, integrator_timer_interrupt never acks the
timer interrupt, instead, it gets ack'ed and unmasked in
__ipipe_ack_timerirq, installed as an acknowledge function for the timer
IRQ in __ipipe_enable_pipeline.
--
Gilles Ch
e, its allocation
seems better by the data structure functions. It also make the binary
heap structure reusable for other purposes.
Could you explain why the current scheme is not robust ?
--
Gilles Chanteperdrix.
__
Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
> > Jan Kiszka wrote:
> > > Hi,
> > >
> > > this patch moves the heap for scalable timer queues into the xnpod_t
> > > structure instead of allocating it dynamically. This simplifies the pod
storage was dynamically allocated by the caller.
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
> > I would also prefer passing the bheaph_t** storage to bheap_init, and
> > conserve bheap_destroy (with a callback called with the bheap_t**
> > storage) in case the storage was dynamically allocated by the caller.
Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
> > bheap_destroy allow
> > setting the bheap_t structure to an invalid value which, in turn, allow
> > helping upper layers in catching invalid uses of the bheap after its
> > destruction.
>
> Ok, we coul
testing tool is called switchtest, because there is already a context
switch benchmarking tool called "switch".
--
Gilles Chanteperdrix.
--- /dev/null 2006-05-03 22:25:59.0 +0200
+++ include/rtdm/switchtest.h 2006-05-31 08:04:01
Jan Kiszka wrote:
> Be warned, this patch is only compile-tested, I'm in a hurry.
I tested the lightly modified version attached and it works. Do you
agree with my changes ?
--
Gilles Chanteperdrix.
Index: ksrc/nucleus
Wolfgang Denk wrote:
> Please consider applying the following trivial patch:
Applied, thanks.
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listi
Heikki Lindholm wrote:
> Gilles Chanteperdrix kirjoitti:
> > Now that the big context switches bugs have been solved, here is a patch
> > that adds a unit test for context switches and FPU switches
> > with various type of threads (kernel, user, user in secondary mod
Gilles Chanteperdrix wrote:
> Heikki Lindholm wrote:
> > Gilles Chanteperdrix kirjoitti:
> > > Now that the big context switches bugs have been solved, here is a patch
> > > that adds a unit test for context switches and FPU switches
> > > with various
ower pc is a bit different because the state of the
FPU is saved by the user/kernel switches, but is not the state of the
MSR_FP bit enough to know if FPU was used in kernel-space ?
--
Gilles Chanteperdrix.
___
Heikki Lindholm wrote:
> Gilles Chanteperdrix kirjoitti:
> > Heikki Lindholm wrote:
> > > Yes, Altivec is separate from the FPU. Hopefully nobody uses FPU in the
> > > kernel - AFAIK currently not, but you never know about closed-source
> > > drivers
I always have the NMI
watchdog option enabled. Are you running with or without the tracer ?
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
> > --- /dev/null 2006-05-03 22:25:59.0 +0200
> > +++ include/rtdm/rttesting.h 2006-06-07 18:50:14.0 +0200
> > @@ -0,0 +1,188 @@
> ...
> > + *
> > + * @{
> > + */
> &
Heikki Lindholm wrote:
> Gilles Chanteperdrix kirjoitti:
> > Jan Kiszka wrote:
> > > Gilles Chanteperdrix wrote:
> > > > --- /dev/null 2006-05-03 22:25:59.0 +0200
> > > > +++ include/rtdm/rttesting.h 2006-06-07 18:50:1
it sucks rest of the time nobody knows. Or was that accounted for
> in the code? (Didn't read it all that carefully, lazy me)
That is right, the new implementation compute a different value for each
switch.
--
osix and vxworks tests configurable.
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
time
task in primary mode using the FPU in primary mode.
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
or debugging for some days now, but if any
> of the code goes through sigreturn path, it might be a kernel bug that's
> fixed in 2.6.16.
Anyway, the patch is applied, thanks.
--
Gilles Chanteperdrix.
__
const u32frac_t f)
{
const unsigned long long tmp = mul64by64_high(op, f.frac);
if(f.integ)
return tmp + op * f.integ;
return tmp;
}
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
h, tll);
th = rthal_ullmul(nsh, ns2cyc_scale);
th += tlh;
tll = (unsigned) th << (32 - NS2CYC_SCALE_FACTOR) | tll >>
NS2CYC_SCALE_FACTOR;
th >>= NS2CYC_SCALE_FACTOR;
return __rthal_u64fromu32(th, tll);
}
--
Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
> > Philippe Gerum wrote:
> > > static inline unsigned long long ns_2_cycles(unsigned long long ns)
> > > {
> > > return ns * ns2cyc_scale >> NS2CYC_SCALE_FACTOR;
> >
> > This
yet refuses the get benchmarked.]
Since we accept a smaller range, I think you should benchmark
nodiv_imuldiv instead of nodiv_ullimd. And it should perform better
since it uses 32 bits shifts which are not real shifts.
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Jan Kiszka wrote:
> Hi,
>
> __rthal_generic_div96by32 from asm-generic/hal.h looks similar to
> __rthal_div96by32 from asm-i386/hal.h. Shouldn't this get cleaned up?
This can not get cleaned up easily.
--
Gil
the family.
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
receiver receive
the null length message with vxworks ?
> -rc = msgQReceive(qid,(char *)&msg,0,NO_WAIT);
> -TEST_ASSERT(rc == ERROR && errno == S_msgQLib_INVALID_MSG_LENGTH);
Null length message again, does this work with the real vxworks ?
&
When using xenomai trunk, it appears that /proc/xenomai is no longer a
directory but a file returning "0".
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://ma
Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
> > When using xenomai trunk, it appears that /proc/xenomai is no longer a
> > directory but a file returning "0".
> >
>
> Check your recent changes for giving the nucleus a regular syscall
> tabl
e that would prevent
> this. Btw, I'd say that "core" would be better than "xenomai" to name
> this internal interface.
Ok for renaming. But no thread is ever bound to this interface, so the
count is always 0.
--
Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
> > Philippe Gerum wrote:
> > > This said, the other option would be to move the call to
> > > xnshadow_mount() from the xnarch_init() to __xeno_sys_init() in a
> > > kernel-only section, just after x
he compiler is right, but it has no consequence, the values of the
swt structure are overriden by an ioctl later on. Anyway, I can set all
this to zero to please the compiler.
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
ures/ 55 tests
Commit 1221 fix it. Thanks for reporting (and running the testsuite).
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
ull
length messages while two receivers are blocked in a call to msgQReceive
?
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Niklaus Giger wrote:
> Am Samstag, 17. Juni 2006 19:53 schrieb Gilles Chanteperdrix:
> > Niklaus Giger wrote:
> > > Hi
> > >
> > > Here the reworked patch.
> > >
> > > vxWorks supports empty messages. Only one at a time can be rece
Jan Kiszka wrote:
> Hi Gilles,
>
> this patch avoids type-mismatch warning when building for 2.4.
>
> Jan
Applied, thanks.
--
Gilles Chanteperdrix.
___
Xenomai-core mailing li
SEQ("Peer",14),
-SEQ("root",1),
+SEQ("root",6),
END_SEQ);
The count is 2 here.
--
Gilles Chanteperdrix.
_
the DMA.
Xenomai allow you to map to user-space some physically contiguous RAM
region (using either native heaps or posix shared memory smaller than
128K), but does not provide accessors to the RAM physical
address. Is it what you need ?
--
Gilles C
tion: the nucleus was still compiled in, the native skin was missing.
After a more thorough inspection, the problem was the xnshadow_p() call
at the very end of do_losyscall_event. When no pod is loaded this call
oopses.
--
at everything is okay!
Patch applied, thanks.
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
ways we can fix this problem:
- either we make the nucleus paranoid and have it handle gracefully
syscalls to non loaded tables;
- or we make the user-space RTDM library behave like other skins and
exit if the interface is not bound.
--
Philippe Gerum wrote:
> On Fri, 2006-06-23 at 15:41 +0200, Gilles Chanteperdrix wrote:
> > Jan Kiszka wrote:
> > > Jan Kiszka wrote:
> > > > Hi,
> > > >
> > > > wondering why suddenly things crash on invoking the latency test, I
>
Gilles Chanteperdrix wrote:
> misinterpretation. When issuing syscalls with a fixed muxid whereas
> there is no interface corresponding to this muxid, the nucleus crashes,
> but it is acceptable, user-space interfaces should issue an
> __xn_sys_bind syscall first.
This is not e
amely mutexes, condition variables and semaphores)
to be automatically destroyed when the process that created them
terminates. Fortunately, since past versions ignored this attribute,
setting it works for both past and future versions.
--
Gilles
Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
> > Gilles Chanteperdrix wrote:
> > > misinterpretation. When issuing syscalls with a fixed muxid whereas
> > > there is no interface corresponding to this muxid, the nucleus crashes,
> > > but it is acce
if (lat < min_lat)
> +min_lat = lat;
> +if (lat > max_lat) {
> +max_lat = lat;
> +if (trigger_trace) {
> +if (port_type == SERPORT) {
> +
splay" thread, whereas the termination
signals are preferably delivered by the kernel to the "main" thread,
that only calls pause. Which makes the use of stderr in signals handlers
pointless.
Anyway, since your program is frequently using printf on the context of
the main th
a different file descriptor in the signal handler and
on the interrupted context.
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
is probably
because its implementation changed without its documentation.
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
eal_pthread_setschedparam, and added a wrapper for
pthread_getschedparam. I will add support for this XNRPIOFF bit to
pthread_set_mode_np. This avoid the need for brain cycles.
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
mach_set_dec(delay);
}
And define __ipipe_mach_min_delay to be 8 ticks for the PXA architecture ?
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Gilles Chanteperdrix wrote:
> Detlef Vollmann wrote:
> > It's not so difficult to work around the problem for a single system.
> > What's difficult is to find a solution in a framework that wasn't
> > built with such a problem in mind.
>
> Actu
Detlef Vollmann wrote:
> Gilles Chanteperdrix wrote:
> > You can even do this in __ipipe_mach_set_dec, this avoid the need to
> > modify I-ipipe non-machine specific code. Something like:
> >
> > void __ipipe_mach_set_dec(unsigned long delay)
&
bugous attempt at mixing things.
Beware, when xnpod_schedule is called from within
xnpod_migrate_thread(), the sched pointer of the switched out thread is
the one of the destination cpu. So, passing the sched and threadout
pointers to xnpod_acc_exec_time is safer.
Philippe Gerum wrote:
> On Fri, 2006-07-07 at 01:47 +0200, Gilles Chanteperdrix wrote:
> > Philippe Gerum wrote:
> > > > +#ifdef CONFIG_XENO_OPT_STATS
> > > > +static inline void xnpod_acc_exec_time(xnsched_t *sched,
> > > > +
t rid of xnpod_migrate_thread(), it is currently not used by
any skin.
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
rg/public/xenomai-core/2006-06/msg00222.html
and continued in july at:
https://mail.gna.org/public/xenomai-core/2006-07/msg3.html
I do not know about the status of their work, but maybe they will be
willing to give a more detailed answer.
--
Hi,
configure script --enable-linux-build option is not yet documented, here
is, for reviewn, a patch which attempts to fill this gap:
--
Gilles Chanteperdrix.
Index: README.INSTALL
atchdog test. Maybe some setups are not done at Linux level
when this test fails, which could explain some weird behaviour
afterwards.
Do you have the message:
Testing NMI watchdog... CPU#0: NMI appears to be stuck (x->y)!
In Linux boot messages ?
--
and see if the /proc display moves ?
--
Gilles Chanteperdrix.
Index: ksrc/arch/i386/nmi.c
===
--- ksrc/arch/i386/nmi.c(revision 1316)
+++ ksrc/arch/i386/nmi.c(working copy)
@@ -6
Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Sun, 2006-07-09 at 18:56 +0200, Jan Kiszka wrote:
> > > I can confirm the failing NMI test here on my notebook with both nucleus
> > > and native skin built into the kernel. I haven't seen false po
h is that you are counting
(rounded_hsize - hsize) as part of the overhead, whereas you would like to
count it as free space. Would not it make more sense to do the rounding
in xnheap_init_mapped ?
--
Gilles Chanteperdrix.
___
Jan Kiszka wrote:
>
> -if (xnpod_unblockable_p()) {
> +if (xnpod_locked_p()) {
Why not if (task == xeno_current_task() && xnpod_unblockable_p()) ?
--
Gilles Chanteperdrix.
___
s wanted: someone really thought about
> it! :)
>
> I tried to bundle your approach with appropriate documentation update
> and a minor fix in the attached patch. Credits go to you then.
Patch applied.
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
xn_mux_code(shifted_id,op) ((op << 24)|shifted_id|(__xn_sys_mux &
> 0x))
Should not this be (op << 16) ?
> +#define __xn_mux_shifted_id(id) (id << 24)
--
Gilles Chanteperdrix.
_
the generic initialization code is
that RTDM did not call exit upon failure to bind, and let a later call
to open fail. I do not know if it was desirable, but it was a feature of
the previous implementation.
--
Gilles Chanteperdrix.
___
ta) {
Should not this rather be if (XNARCH_HOST_TICK) ?
> +xnlock_get_irqsave(&nklock, s);
> +xntimer_start(&nkpod->htimer, delta,
> + XNARCH_HOST_TICK / nkpod->tickvalue);
> +xnlock_put_irqrestore(&nklock, s);
> +
o this requirement, provided the implementation is
> confined to xnpod_suspend_thread() + xntimer_start().
It would be nice if absolute timeouts were also available when using
xnsynch_sleep_on. There are a few use cases in the POSIX skin.
--
ould be simpler to completely avoid
sched_setaffinity over UP machines.
The proper fix is to also define cpu_set_t when CONFIG_SMP is not set.
I will fix this.
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
+#error It conflicts with Xenomai's TSC emulation.
> +#endif /* CONFIG_INPUT_PCSPKR */
> +
> #define RTHAL_8254_COUNT2LATCH 0xfffe
> void rthal_setup_8254_tsc(void);
> rthal_time_t rthal_get_8254_tsc(void);
How about solving this in Kconfig ?
--
Gilles Chanteperdrix wrote:
> How about solving this in Kconfig ?
> Index: scripts/Kconfig.frag
> ===
> --- scripts/Kconfig.frag (revision 1388)
> +++ scripts/Kconfig.frag (working copy)
> @@ -2,6 +2,7
_db.so.
--
Gilles Chanteperdrix.
#include
void *routine(void *cookie)
{
pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);
for (;;)
;
return cookie;
}
int main(int argc, const char *argv[])
{
pthread
201 - 300 of 2013 matches
Mail list logo
